Re: Bug: Inconsistent macro replacement [9.4.4 (release_9.4.4 @ /nix/store/jzj2bbfjlbv08xjgyljf7aqf7q2jcbm8-emacs-27.2/share/emacs/27.2/lisp/org/)]

2021-10-23 Thread Nicolas Goaziou
Hello,

Vinicius Vinicius  writes:

> While {{{title}}} concatenates multiple #+TITLE lines, {{{author}}} retrieves 
> only the first one.
>  
> MWE:
> #+TITLE: Foo
> #+TITLE: Foo2
>  
> #+AUTHOR: First Author
> #+AUTHOR: Second Author
>  
> {{{title}}} vs {{{author}}}

Fixed.

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: the tangled web of org-cite, selectrum, completing-read, ...

2021-10-19 Thread Nicolas Goaziou
Eric S Fraga  writes:

> For the record, in the end, I needed to do the following:
>
>   1. set =org-cite-basic-author-column= to a larger number

You can ignore this step, which is useful (but is not as you report)
only when using `basic' insert processor. Here, you're using a different
insert processor.

Regards,



Re: the tangled web of org-cite, selectrum, completing-read, ...

2021-10-19 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> TL;DR: how can I format the suggestions listed by selectrum when I ask
> to insert a citation with org-cite-insert?
>
> Longer version: I use selectrum a my completion engine together with
> marginalia.  This works very well for most selections I wish to
> make.  However, for org-cite, the display has the author list truncated
> (to 25 characters; screenshot image attached, assuming it doesn't get
> removed by the mailing list server)

You can set `org-cite-basic-author-column-end' to a higher value.

> and the search only appears to
> consider the truncated text.  The result is that if I am looking for a
> paper by an author (say Kitchin ;-)) who is not one of the first few
> authors on a particular publication, I won't be able to find that
> particular publication (sorry John).
>
> I have no idea which bit of the tool chain does the
> formatting/truncation or whether I can make the search ignore the
> truncated information.

You are using the `basic' back-end for insertion. You may want to use
something else by setting `org-cite-insert-processor' to an appropriate
value, e.g., `oc-bibtex-actions'.

I hoped it would also be possible to set it to something like `org-ref'
or some such, but it doesn't seem it will happen.

Regards,
-- 
Nicolas Goaziou



Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

2021-10-15 Thread Nicolas Goaziou
Hello,

Leszek Wroński  writes:

> Guys,

and gals!

> The introduction to chapter 15 says 'The included “basic” processor
> provides all four capabilities.' (w.r.t. 'activate', 'follow',
> 'insert', 'export'). I thus assumed that the basic processor was
> included. However, org-cite-insert ended with 'Unknown processor
> basic'.

This is rather unexpected. Your assumption is correct, oc-basic should
be available right from the start. I fixed it in bugfix branch.

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: resume an interrupted enumerated list or reset the counter

2021-10-15 Thread Nicolas Goaziou
Hello,

Uwe Brauer  writes:

> Right in a org buffer! But not say in a message buffer, using
> orgalist-mode.

Orgalist minor mode is not Org mode. In particular, the former has no
knowledge about source blocks.

You can either indent the contents of the source block appropriately, or
use an ugly number cookie:

 1. Item 1
 3. [@3] Item 3

Regards,
-- 
Nicolas Goaziou



Re: A minor suggestion about formatting citations

2021-10-13 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> On Mon, Oct 11, 2021 at 11:54 AM Nicolas Goaziou  
> wrote:

>> I don't think that's totally true. The additional space makes sense
>> typographically, in particular when some suffix is associated to the
>> key.
>
> Can you give an example of what you mean here? I can't think of one
> off the top-of-my-head.

I mean that it seems natural to write, e.g.,

 [cite:@doe21 p. 1; @doe99]

instead of 

  [cite:@doe21 p. 1;@doe99]

>> Org Cite is unrelated to this. One could as well have inserted spaces
>> manually, i.e., without calling `org-cite-insert' at all.
>
> I know; but you changed the default behavior of 
> org-cite-make-insert-processor.
>
> The OP asked if there were any implications for this generally, and
> I'm just saying "yes, there is."

OK. Then, we are in a violent agreement. :)

> You do have to trim the whitespace on either side of the key, since
> the space is the delimiter. I guess it's not possible for the citation
> parser to ignore the other whitespace?

I'm not sure to understand your question. The space is not the
delimiter; the semicolon is.

For now, the whitespaces are significant for the parser, barring the
leading and trailing ones. It seemed useful for export back-end and
citation processor combinations unable to handle punctuation
automatically (e.g., HTML + oc-basic). I can't tell if they should be
ignored instead.

>> The functions responsible for swapping citations ought to cope with this 
>> situation
>> too.
>
> So check if the content of an affix, for example, is " " (rather than
> whether there's an affix), and adjust accordingly?

I don't think you need to check affixes when cycling citation
references. You could split at ";", trim, re-order, and re-build the
contents inserting "; " between each reference.

Regards,
-- 
Nicolas Goaziou



Re: Citations: non-page locators placed in front of citation

2021-10-11 Thread Nicolas Goaziou
M. ‘quintus’ Gülker  writes:

> Long story short: I do not think that it is a bug in locales-de-DE.xml,
> and I guess Pandoc proves my point here. Please map § to "section"
> instead of "paragraph" in org-cite, i.e., do it the way Pandoc does
> it.

I mapped both § and §§ to "section". Hopefully, the issue is now
completely fixed.

Regards,



Re: A minor suggestion about formatting citations

2021-10-11 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> On Mon, Oct 11, 2021 at 10:28 AM John Kitchin  wrote:
>>
>> you should probably trim each key, and re-add spaces where you want them in 
>> the function that does these kinds of things.
>
> I realize that's an option, but something about that feels wrong to me.
>
> We're adding a single space as prefix, not because it's meaningful for
> citation purposes (there actually is no prefix, though org-cite
> interprets it as " "), but only so buffer formatting works correctly.

I don't think that's totally true. The additional space makes sense
typographically, in particular when some suffix is associated to the
key.

> And then presumably code needs to be added to the export machinery to
> strip those empty affixes?

I think they are ignored already. I didn't check though.

> Am not saying the latter goal isn't important; just seems like the
> side effect isn't ideal.
>
>> Maybe that should even be controlled by a defcustom that allows 0-1 spaces.
>
> You mean in org-cite? I think that'd be my preference, unless there's
> a better solution to this issue.

Org Cite is unrelated to this. One could as well have inserted spaces
manually, i.e., without calling `org-cite-insert' at all. The functions
responsible for swapping citations ought to cope with this situation
too.

Regards,
-- 
Nicolas Goaziou



Re: A minor suggestion about formatting citations

2021-10-11 Thread Nicolas Goaziou
Hello,

Vikas Rawal  writes:

> I find it works better for me if I insert spaces between multiple
> citations. For example: [cite: @john56; @john35; @bruce2021] rather
> than [cite:@john56;@john35;@bruce2021].
>
> The of advantage is that if I am citing many references in one place,
> and use fill-paragraph/auto-fill, they wrap nicely. As far as I can
> see, having spaces in between works just fine.
>
> If this does not break anything, should this be the recommended
> practice for the org-cite-insert-processors?

Done, at least for insert processors relying on
`org-cite-make-insert-processor'. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: Citations: non-page locators placed in front of citation

2021-10-11 Thread Nicolas Goaziou
Hello,

M. ‘quintus’ Gülker  writes:

> Now it’s getting wild.

Indeed. The "fix" I introduced was a mistake. I pushed a new fix.
I think the initial issue is solved now. Could you confirm it?

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: Citations: non-page locators placed in front of citation

2021-10-11 Thread Nicolas Goaziou
Hello,

András Simonyi  writes:

> looks like an Org (oc-csl) side locator parsing problem to me, because
> using the alternative [cite:@saenger2013gsr para. 12 Rn. 488] form I
> seem to get the correct result. Can it be a regex matching problem
> with the paragraph symbols?

You're right. I thought I had solved the regexp part but I was wrong.
I pushed a new attempt to solve this.

Sorry for the noise.

Regards,
-- 
Nicolas Goaziou



Re: [org-cite] add convention for direct commands, process for adding mappings to export processor(s)?

2021-10-10 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

>> The current list of styles and variants included in the oc export
>> processors was a first step, with a goal to provide a solid starting
>> point, and citations that are more-or-less portable across the
>> backends.
>>
>> But that raises an obvious question: what next?

Are we at next already?

>> I'd like, for example, to suggest adding "noauthor/bare" -> "cite*" to
>> oc-biblatex.

Done.

>> I also think we should add a way for users to use a direct command for
>> natbib and biblatex.

[...]

>> Perhaps some prefix for a style that signals to pass on directly for a
>> specific export processor; like [cite/blx+footcite ...].

I'm not too keen on extending the citation syntax.

>> In that case, the oc-biblatex processor would pass that command on as
>> is, but other processors would ignore it, and use the default
>> instead.

This is the point of styles. We could allow custom ones.

>> And if we were to add this, we'd still need to answer my first
>> question: when and how to add specific style/variant mappings to the
>> oc processors.

It is possible to send a patch if it is something useful. Some
processors (probably only biblatex at this point, we probably cover
everything in natbib) may also introduce a customizable variable for
user-defined styles.

Regards,
-- 
Nicolas Goaziou



Re: Citations: non-page locators placed in front of citation

2021-10-10 Thread Nicolas Goaziou
Hello,

M. ‘quintus’ Gülker  writes:

> I however do not think the problem is related to the NBSP. I just
> retried without it, and the § sign is still pulled towards the front.
> I also retried with current Git (Org mode version 9.5
> (release_9.5-93-gd87250 @ /home/quintus/.emacs.d/org-mode/lisp/)), but
> that does not change anything. Either with the NBSP or with a normal
> space, the § sign is pulled toward the front. That is,
>
> Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].
>
> Still yields:
>
> §  Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488
>
> Without the NBSP, that is,
>
> Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].
>
> it yields:
>
> § Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488
>
> Neither is correct; the § should go after the "2013, ".

Then, this may be a bug in Citeproc library itself. I suggest to report
it upstream.

Regards,
-- 
Nicolas Goaziou



Re: [org-cite] allow citations in captions?

2021-10-10 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> Is there any technical reason citations aren't allowed in captions?

Yes, there is. Captions are somewhat fragile: they may or may not be
included in the final output. So this might introduce some subtle bugs,
such as pointers (op. cit., or ibid) to non-existing references. For the
same reason, footnotes references are not allowed in citations either.
I don't know if the benefits outweigh these possible complications.

Regards,
-- 
Nicolas Goaziou



Re: Citations: non-page locators placed in front of citation

2021-10-10 Thread Nicolas Goaziou
Hello,

M. ‘quintus’ Gülker  writes:

> apologies for my frequent e-mails. It’s just that I am evaluating the
> citations facility for me.

On the contrary, feedback on citations is very much welcome. This is
a new features, and as such, has some rough edges.

> This time it’s about non-page locators. Take the following document:
>
> #+TITLE: Test
> #+AUTHOR: testauthor
>
> #+LANGUAGE: de
> #+bibliography: /tmp/mwe/mwe.bib
>
> #+cite_export: csl /tmp/mwe/juristische-schulung.csl
>
> Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].
>
> juristische-schulung.csl is
> https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl.
>
> This is mwe.bib:
>
> @Book{saenger2013gsr,
>   author   = {Ingo Saenger},
>   title= {Gesellschaftsrecht},
>   year  = {2013},
>   edition   = {2},
>   publisher = {Franz Vahlen},
>   location  = {München},
>   langid= {ngerman}}
>
> Note how this work is not cited by page, but instead (which is common
> among German judicial literature) by section number (§) plus margin number
> (Rn.). Exporting this e.g. to HTML yields in Footnote 1:
>
> §  Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 12 Rn. 488
>
> That is rather unexpected. It has pulled the § sign in front of the
> citation. The citation should have looked like this:
>
> Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488

[...]

> Is it a bug or (again) my error?

It is a bug. You use a non-breaking space between the locator and the
number. I hadn't anticipated this (duh!). I fixed it. Could you confirm
it?

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: test-org-cite/list-citations failure

2021-10-09 Thread Nicolas Goaziou
Hello,

Kyle Meyer  writes:

> It looks like this commit introduced a test failure.

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



[ANN] New `bibtex' citation processor

2021-10-08 Thread Nicolas Goaziou
Hello,

I just added the no-thrill "oc-bibtex" citation processor, which relies
on the standard "\cite" and "\nocite" LaTeX commands. It only supports
citation suffixes.

Regards,
-- 
Nicolas Goaziou



Re: Citations: Locale specific adaptions?

2021-10-08 Thread Nicolas Goaziou
M. ‘quintus’ Gülker  writes:

> I agree with Bruce that this should be mentioned in the manual,
> including a pointer to the aforementioned Git repository, because I
> needed to find that one on my own.

Meanwhile, the `csl' processor is copiously documented in the
"Commentary" section of the "oc-csl.el" file.

Regards,



Re: Citations: Locale specific adaptions?

2021-10-08 Thread Nicolas Goaziou
Hello,

M. ‘quintus’ Gülker  writes:

> CSL has a concept of locales, where things like specific terms or the
> date format are drawn from locale files (see
> https://docs.citationstyles.org/en/1.0.1/specification.html#locale). I
> am not entirely sure if this is supported yet by the new citations
> functionality. Take this test document test.org:
>
> #+TITLE: Test
> #+LANGUAGE: de
>
> #+AUTHOR: Testauthor
> #+bibliography: /tmp/test/test.bib
>
> #+cite_export: csl /tmp/test/juristische-zitierweise.csl
>
> Das ist ein Test. [cite: @boehme-neßler2017unscharfes-recht-digital p. 
> 3033] Zweiter Satz.
> Noch ein Test. [cite: @akbarian2020oeffentliche-raeume]

[...]

> juristische-zitierweise.csl is a style for longer judicial works and
> available from the CSL repository at 
> https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-zitierweise.csl.
>
> Given that test.org spefies “#+LANGUAGE: de”, I would expect that
> exporting uses the German terms and date format. However, exporting e.g.
> to HTML gives this in the bibliography:
>
> Akbarian, Samira, An einen, der vorüberfuhr, Stand: December 14,
> 2020, https://verfassungsblog.de/an-einen-der-voruberfuhr/
> (accessed 01/02/2021).
>
> The correctly German word “Stand” is hardcoded in
> juristische-zitierweise.el, so ignore that one for a moment. Other than
> that, you will notice that the date format is US English. This should
> not be the case. 

I think you need to provide locales in addition to the style file, see
`org-cite-csl-locales-dir'.

Regards,
-- 
Nicolas Goaziou



Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

2021-10-06 Thread Nicolas Goaziou
Hello,

Elias Bounatirou  writes:

> However, it appears Nicolas' MWE unfortunately does not  reproduce the
> issue. It's not the footnote that is omitted/ not exported, it's the
> citation in the footnote that is left out (when the footnote follows two or
> more citations, of which one has a suffix). In Nicolas' MWE, there is no
> citation in the footnote. What seems to me (being no export on LaTeX)
> strange about Bruce's LaTeX output is that there is no command
> \footnote{...} or the like. So is the footnote-part of the LaTeX output
> real LaTeX? (Sorry for this naïve question.)

I noticed my ECM was not right. It took me a while to figure out the
issue.

> I've tested again.
> With verbose I get the same erroneous result: the citation in the footnote
> is not rendered (using the development version of org-mode, see below):
> INPUT:
>

[...]

> Body text [cite: @ravlic2021; @saric2010 with a SUFFIX][fn:1]

[...]

> [fn:1]Test [cite: @senker1987]
>
> LaTeX OUTPUT (shortened):
>
> Body text \autocites{ravlic2021}[][with a SUFFIX]{saric2010}\footnote{Test}

I think I fixed it. Could you confirm it?

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

2021-10-06 Thread Nicolas Goaziou
Hello,

Ihor Radchenko  writes:

> Nicolas Goaziou  writes:
>
>> Also, the fix belongs to `org-get-time-of-day', which is also
>> responsible for formatting the output.
>
> I doubt so. `org-get-time-of-day' is used to format ending time in time
> ranges.  If we force fixed width in `org-get-time-of-day', we may have
> something like " 8:00- 9:00" instead of " 8:00-9:00".  On the other
> hand, the current behaviour for non-nil org-agenda-timegrid-use-ampm, we
> already have "8am- 9am" even without the patch.
>
> WDYT?

Fair enough. I think I should not even try to understand
"org-agenda.el".

Regards,
-- 
Nicolas Goaziou



Re: Citation not inserted as 1st item in footnote (using org-cite and org-ref-cite)

2021-10-06 Thread Nicolas Goaziou
Nicolas Goaziou  writes:

> This allows one to insert a citation in the middle of the citation
> number, which is not desirable either. IOW, an additional check is
> required.

I think this is now fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: Citation not inserted as 1st item in footnote (using org-cite and org-ref-cite)

2021-10-05 Thread Nicolas Goaziou
Hello,

Elias Bounatirou  writes:

> I have looked at the problem that citations cannot be inserted as 1st items
> in footnotes once again more closely. It has become obvious for me that
> this is indeed a bug of org-cite or rather a default setting which was
> deliberately introduced, although it is not really user-friendly or
> practical to my mind.

This is not intentional.

> I modified the function org-cite--allowed-p in oc.el  and inserted
> 'footnote-definition' in the following lines:
>
> ;; Paragraphs and blank lines at top of document are fine.
>  ((memq type '(nil paragraph footnote-definition)))

This allows one to insert a citation in the middle of the citation
number, which is not desirable either. IOW, an additional check is
required.

Regards,
-- 
Nicolas Goaziou



Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

2021-10-04 Thread Nicolas Goaziou
Hello,

M. ‘quintus’ Gülker  writes:

> Ah, I see. Thank you for the pointer. I created an issue ticket with a
> copy of the OP here:
> <https://github.com/andras-simonyi/citeproc-el/issues/54>

Great! Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

2021-10-04 Thread Nicolas Goaziou
Hello,

Max Nikulin  writes:

> On 04/10/2021 14:48, Ihor Radchenko wrote:
>> tumashu writes:
>>>
>>> When I update to org 9.5,  I find that  the align of time like "7:00" has 
>>> been changed.
>>>
>>> I think the new style is not beautiful as old style.
>>>   1. New style look like not align to  the first char, for the
>>> width of 9 looks like > 1
>>> 2. the old style is align ":"
>> The attached patch should fix the issue. Please, test it though.
>> I do
>> not use time grid regularly.
>
>> -  (when s1 (setq s1 (org-get-time-of-day s1 'overtime)))
>> +  (when s1 (setq s1 (format "%05s" (org-get-time-of-day s1 'overtime
>
> I think, "%5s" is enough, flag "0" does not anything useful for
> strings.

Also, the fix belongs to `org-get-time-of-day', which is also
responsible for formatting the output.

Regards,
-- 
Nicolas Goaziou



Re: "Unknown processor biblatex"

2021-10-04 Thread Nicolas Goaziou
Hello,

Colin Baxter  writes:

>>>>>> Bruce D'Arcus  writes:

> > You have to load oc-biblatex, say using use-package, and also set
> > org-cite-export-processors, like:
>
> > (setq org-cite-export-processors '((latex biblatex) (t csl)))
>
> Great, but what about old timers like me who insist on using bibtex?

What do you mean by "using bibtex"? In particular, what package, if any,
do you use to actually cite something? Do you limit yourself to the
built-in "\cite" and "\nocite" commands? If that's the case, there is no
support for it yet, though it should be trivial to add some.

> I sympathise with the op in not getting this new org-cite to
> work. It has beaten me despite repeated efforts.

You may want to report what didn't work for you.

Regards,
-- 
Nicolas Goaziou



Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

2021-10-04 Thread Nicolas Goaziou
Hello,

Marvin Gülker  writes:

> I've been trying to use the new citation facilities in the just-released
> 9.5 version of org for a simple test document with my preferred CSL
> style (the one usually used in German law discipline in one way or
> another), but did not have luck with it so far. That being said,
> exporting with the default "bare" citation processor appears to be fine.
> With the "csl" processor, I receive this error when I export to LaTeX
> with `org-latex-export-as-latex':
>
> Debugger entered--Lisp error: (wrong-type-argument sequencep splice)
>   citeproc-rt--cquote-pstns-1(splice 15)

It looks like the issue is in the Citeproc library, not in the Org
wrapper. You may want to report it upstream.

Regards,
-- 
Nicolas Goaziou



Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

2021-10-03 Thread Nicolas Goaziou
Hello,

Elias Bounatirou  writes:

> Just to clarify the BUG:
> Citations in a footnote in the following environment are not exported to
> LaTeX: when the footnote follows two or more citations, of which one has a
> suffix, i.e. for instance in
>
> Body text with a citation: [cite:@low2001; @mcneill2011 with a
> suffix][fn:3].

I cannot reproduce the problem. With the following document:

--8<---cut here---start->8---
#+bibliography: foo.bibtex
#+cite_export: biblatex authoryear

Body text with a citation: [cite:@foo; @bar with a suffix][fn:1].

* Footnotes

[fn:1] Test 
--8<---cut here---end--->8---

I get,

--8<---cut here---start->8---
Body text with a citation: \autocites{foo}[][with a suffix]{bar}\footnote{Test}.
--8<---cut here---end--->8---

If I write

--8<---cut here---start->8---
Body text with a citation: [cite:@foo; @bar; with a suffix][fn:1].
--8<---cut here---end--->8---

instead, I get

--8<---cut here---start->8---
Body text with a citation: \autocites(with a 
suffix){foo}[][]{bar}\footnote{Test}.
--8<---cut here-------end--->8---

Both seem correct.

Regards,
-- 
Nicolas Goaziou



Re: Spurious spaces with oc-biblatex

2021-10-03 Thread Nicolas Goaziou
Hello,

Denis Maier  writes:

> Elias and I have run into an potential bug in oc-biblatex:
>
> ==
> #+cite_export: biblatex authoryear
>
> [cite:@doe] => ok
>
> ([cite:@doe]) => this generates a space between the opening
> parentheses and the citation.
> ==
>
> Result:
>
> 
> \autocite{doe}
>
> ( \autocite{doe}) => this generates a space between the opening
> parentheses and the citation.
> =========

Fixed.

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Don't fill displayed equations

2021-10-02 Thread Nicolas Goaziou
Hello,

Timothy  writes:

> Is it? I can't use verbatim like this:
>
> =
> some
> verbatim
> text
> =
>
> but I can do
>
> \[
> some
> display
> equation
> \]
>
> It seems to me that \[ ... \] is already treated differently from other
> inline markup.

There is some misunderstanding here. 

You cannot use verbatim like the above because its definition forbids
spaces on the inner side of the markers (for obvious reasons). There is
no such restriction in \[...\] markup. For citations, you can also write

  [@cite:
  @foo
  ]

if you like.

But this is orthogonal to the type of element, i.e., inline or block.

Inline means the object is always enclosed in a paragraph (or a verse
block, or possibly a table cell). In particular, it cannot get past the
boundaries of its container. Corollary: since a blank line in Org ends
a paragraph, objects cannot contain blank lines. Both verbatim objects
and \[...\] snippets share those limitations.

> If that's the only way that Org could treat \[ ... \] differently from
> \( ... \), I'd be strongly in favour of this.

I think it is not necessarily a bad thing that \(...\) and \[...\] are
the same. Some export back-ends can tell the difference between them,
others do not care. This is the same for, e.g., verbatim and code. Not
all back-ends use a different output for them. IOW, it is not
necessarily right to treat them differently just because some back-ends
do treat them differently. Org is simply agnostic to this subtleties.

> I prefer \[ ... \] over \begin{equation*}...\end{equation*} as it's much
> more succinct, and helps reduce the "markup noise" in my documents. 

This is all about taste. But at least you have a choice. With your
patch, I may have to struggle with filling whenever some paragraph
contains \[...\], without any choice.

Also, it could be possible to overlay "\[" over \begin{equation*} thus
negating the markup noise.

> I don't think this is an insignificant concern, brevity may not be
> something I'm very good at in emails  but is something I look for in
> syntax.

You probably have noticed that Org syntax is not very much into brevity.

> I must admit, I don't see the downside here --- how does this break the
> filling function for the rest of you? This only affects \[ ... \] blocks
> that have already been put on their own line.

No it doesn't. Without additional guards, filling a paragraph could
split a line and send an otherwise mid-line block at the beginning of
a line. But this is not the point. The point is much more basic,
actually. It is related to the uniformity of filling behaviour, as
already explained.

> Why can't we apply LaTeX expectations to LaTeX elements in Org? Applying
> LaTeX expectations to Org as a whole is clearly a silly idea, but Org
> copies \[ .. \] from LaTeX and it is a LaTeX construct.

Nope, it is obviously borrowed to LaTeX, but they are not the same.

I think I understand where you're coming from. Relying much on LaTeX,
you probably grew habits on how your equations should be formatted in
a LaTeX document. Applying this formatting in an Org document doesn't
work, tho, because Org has little understanding of true LaTeX syntax. It
just needs a way to quickly write maths.

  \[
  ... equation ...
  \]

should be seen as a LaTeXism.

>> Notwithstanding filling behaviour, \[...\] in Org is much more limited
>> than \[...\] in LaTeX.
>
> I'd be curious to hear how, as I personally haven't run into any
> instances where \[ ... \] has behaved differently other than when an
> environment starts on a new line in of a \[ ... \] block (which can
> easily be fixed by putting something like \!\ at the start of the
> line).

As explained above, for example, \[...\] cannot contain blank lines.
They cannot contain, e.g., "|" at the beginning of a line, too.
Full-fledged LaTeX environments do not have those limitations.

> I don't want "advanced" LaTeX code, I just want my display equations to
> be treated as display equations consistently .

It is a "display equation" in LaTeX. There is no such thing as
a "display equation" in Org, even though you probably see it as such due
to your LaTeX background. There, \[...\] is just another way to write
maths within a paragraph.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Don't fill displayed equations

2021-10-01 Thread Nicolas Goaziou
Hello,

Stefan Nobis  writes:

> I wonder, why it is not a block element. As far as I know, the only
> difference (even in the context of Org) between \(...\) and \[...\]
> is, that the former denotes inline math and the latter denotes a math
> block. And at least exporting to HTML (with MathJax) and LaTeX results
> in a block equation for \[...\].

That's not true. Only some export back-ends can tell the difference
between \(...\) and \[...\], so in the context of Org, they are the
same.

> Do you have a short summary or a pointer why \[...\] has been choosen
> to be an inline element? 

Yes: habit. Also, I don't think LaTeX treats it as a block element.
E.g.,

text
\[1+1=3\]
text

is a single paragraph in LaTeX.

> What's the advantage or what would be the downside of making it
> a block element?

If it's a block element, you cannot write \[...\] mid-line. Such
constructs must start at the beginning of the line, barring some initial
indentation. Also, they would end the current paragraph, so the example
above would generate three paragraphs.

The advantage, at least for some users, is that they are not subjects to
filling, and can contain empty lines. This is already provided by
\begin{equation*}...\end{equation*} LaTeX environments.

Regards,
-- 
Nicolas Goaziou



Re: Suggestions for improved suffix parsing in oc-biblatex

2021-10-01 Thread Nicolas Goaziou
Hello,

Denis Maier  writes:

> So, you're suggesting that locator parsing algorithm should be ported
> to oc-biblatex instead?

That's a possibility. It can be factored out from oc-csl.el and become
a generic tool living in oc.el, if deemed useful. The algorithm can trip
over locators involving letters, tho (e.g., "chap. xiv, xv and xvi").
I don't know if that's common.

Moreover this is but one side of the problem. Naively, I thought that
BibLaTeX would take care of parsing the locator. Since that's not the
case, oc-biblatex needs additional code to properly deal with it.

Regards,
-- 
Nicolas Goaziou



Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

2021-10-01 Thread Nicolas Goaziou
Hello,

Ihor Radchenko  writes:

> At this point, third-party code is likely to rely on the existing logic,
> so I do not see any reason to insist on changing org-table.

If you think it is overall an improvement, feel free to discuss it. I'm
merely pointing out what was the initial intent, not necessarily how it
should be.

> To avoid confusion, can we change the docstring explicitly saying that
> empty cells are ignored? (see the attached)

Sure. Thanks.

Regards,
-- 
Nicolas Goaziou



Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

2021-09-30 Thread Nicolas Goaziou
Hello,

Ihor Radchenko  writes:

> Nicolas,
>
> Is there a rationale behind bypassing :fmt and :hfmt for empty table
> cells in `org-table--to-generic-cell'? In this patch, I have to work
> around this using :raw parameter in `orgtbl-to-generic' call. I do not
> feel like such workaround should be needed.

I'm not sure. I wrote this some years ago. I guess the rationale at that
time was that it didn't feel useful to apply a format to an empty cell.
For example, if you use `:fmt "$%s$"', I assume you wouldn't want to get
"$$" in otherwise empty cells.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Don't fill displayed equations

2021-09-30 Thread Nicolas Goaziou
Timothy  writes:

> I think there are also some relevant points which I haven’t mentioned so far,
> separate from my thoughts that since we’re using the LaTeX syntax we should be
> consistent with how LaTeX treats this.

I'm not convinced about this. I don't think it is even possible.

>> As I wrote above, they do not belong to the same category of syntax.
>> There’s no reason to special case 
>
> I think we already do special-case `\[ ... \]' somewhat. When refer to inline
> elements like bold, verbatim, italic, etc. they sit in the text. Semantically,
> this doesn’t hold for `\[ ... \]' either. The semantically inline maths 
> element is
> `\( ... \)'. Considering other “inline” syntax elements, like bold, verbatim,
> italic, etc. if you spread the delimiters across multiple lines that doesn’t
> work. So I’d argue the ship has already sailed on treating `\[ ... \]' 
> differently
> to other inline elements.

I'm not sure about what you mean. \[...\] is no different than, e.g.,
verbatim. It's an inline element, with all that it implies.

Now, if you want to discuss changing syntax for \[...\] and make it
a block element, you can of course do it to your heart's content (it has
been discussed already in this ML and I don't have an opinion on the
subject), but please don't make filling do bizarre things (not all Org
users use LaTeX or even like LaTeXisms), just because LaTeX modes behave
differently.

> If you’re wondering why I’m so opposed to the current behaviour, that is 
> probably
> best explained by a more realistic demo that what I have in the commit 
> message.
>
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving
> │ \[
> │   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
> │ \]
> │ this will be positive over \(x \in (0,D)\), and so we can rewrite 
> \(\tilde{y}\) as,
> │ \[
> │   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi 
> \frac{\frac{D}{2}-x}{2D} \right) + C_2.
> │ \]
> │ Once again considering that \(y(0)=y(D)=0\), it is clear that
> │ \[
> │   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
> \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \]
> │ The complete solution for \(\tilde{y}\) is hence,
> │ \[
> │   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
> \frac{D}{\pi} \log 2.
> │ \]
> └

In every case above, you can already use
\begin{equation*}...\end{equation*}, so I don't see the point. You
already have all you need without breaking filling function for the rest
of us.

> Basically, this leads to a worse experience when using Org in what
> I would think to be a perfectly reasonably way.

I don't think it is a worse experience, unless you apply expectations
from LaTeX to Org. It just doesn't work. Notwithstanding filling
behaviour, \[...\] in Org is much more limited than \[...\] in LaTeX.
They just happen to use the same syntax for convenience in simple cases.
The same holds for, e.g., LaTeX commands. To put it differently, you
cannot just paste some LaTeX code in an Org buffer and expect Org to
properly deal with it. But that's fine. If you need to write or copy
"advanced" LaTeX code, Org provides dedicated environments.

Regards,



Re: [PATCH] Don't fill displayed equations

2021-09-30 Thread Nicolas Goaziou
Hello,

Colin Baxter  writes:

>>>>>> Nicolas Goaziou  writes:
>
> > Timothy  writes:
> >> Nicolas Goaziou  writes:
> >> 
> >>> I strongly disagree with this. \[...\] is an inline element, not
> >>> a block element. As such, it can be filled, and filling function
> >>> should obey to the inner structure of the document.
> >>> 
> >>> You can use a real block element here, e.g.,
> >>> \begin{equation*}...\end{equation*}, which will not be filled.
> >> 
> >> Given that \[ ... \] is an alias for \begin{equation*} ...
> >> \end{equation*}
>
> > This is true in LaTeX, not in Org, obviously.
>
> But shouldn't org be consistent with LaTeX. 

Org supports, as a small part of its syntax, some limited LaTeX markup.
It doesn't imply it should strive for consistency with LaTeX. Actually,
I think it's quite the opposite. Org is not a LaTeX front-end.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Don't fill displayed equations

2021-09-30 Thread Nicolas Goaziou
Timothy  writes:

> Nicolas Goaziou  writes:
>
>> I strongly disagree with this. \[...\] is an inline element, not a block
>> element. As such, it can be filled, and filling function should obey to
>> the inner structure of the document.
>>
>> You can use a real block element here, e.g.,
>> \begin{equation*}...\end{equation*}, which will not be filled.
>
> Given that \[ ... \] is an alias for \begin{equation*} ...
> \end{equation*}

This is true in LaTeX, not in Org, obviously.

> I don't see why it should be treated any differently
> when filling.

As I wrote above, they do not belong to the same category of syntax.
There's no reason to special case \[...\]. 

Filling is a red herring, its outcome depends on the syntax of the
underlying object, as expected. So, as long as \[...\] is an inline
element, it should be filled.

Regards,



Re: [PATCH] Don't fill displayed equations

2021-09-30 Thread Nicolas Goaziou
Hello,

Timothy  writes:

> If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
> should be filled into the rest of the text. I.e.,
>
> ┌
> │ some nice text
> │ \[
> │   1+1=2
> │ \]
> │ more text.
> └
> should not become,
> ┌
> │ some nice text \[ 1+1=3 \] more text.
> └
>
> While the above example may not look bad, with non-trivial equations
> this can become quite messy.

I strongly disagree with this. \[...\] is an inline element, not a block
element. As such, it can be filled, and filling function should obey to
the inner structure of the document.

You can use a real block element here, e.g.,
\begin{equation*}...\end{equation*}, which will not be filled.

Regards,
-- 
Nicolas Goaziou



Re: Suggestions for improved suffix parsing in oc-biblatex

2021-09-30 Thread Nicolas Goaziou
Hello,

Denis Maier  writes:

> Well, there are even cases like this one:
>
> [cite:@doe especially 4, 12, and 15]
>
> [cite:@doe e.g. 4, 12, and 15]
>
> [cite:@doe among others 4, 12, and 15]
>
> [cite:@doe 4, but also 12 and 15]

AFAIU, all these cases are already handled by the locator parsing
algorithm used in oc-csl.el. If that is correct, my point is still the
same: there are very few cases where an explicit locator delimiter would
be necessary.

Note that for clarity, it would help to also specify, along with your
examples, what is the expected locator, and possibly the expected
output.


Regards,
-- 
Nicolas Goaziou



Re: Suggestions for improved suffix parsing in oc-biblatex

2021-09-29 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> That won't work if you have more than one reference in a citation?
>
> [cite:@doe 4, with some more text; @jones]

No, that won't work with more than one reference in a citation. But
this, coupled with the simple locator parsing done in oc-csl.el should
be enough in the vast majority of the cases, shouldn't it?

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Dear András,
>
> András Simonyi  writes:
>
>> the attached patch adds support for the text (textual) and year
>> (year-only) citation styles in the CSL org-cite processor.
>
> Applied, thank you very much!

The function `org-cite-csl--create-structure-params' probably needs to
be refactored, as the pcase pattern is going to put the byte-compiler to
a knee. See, e.g., a6d93cfb621356893dc69fc779894c0984cedbd1 and related
thread at <http://lists.gnu.org/r/emacs-orgmode/2021-08/msg00100.html>.

Regards,
-- 
Nicolas Goaziou



Re: Suggestions for improved suffix parsing in oc-biblatex

2021-09-28 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Denis Maier  writes:
>
>> I think the suffix parsing in oc-biblatex could be improved. 
>
> Can you provide a patch for this?

I don't think this improvement is needed. We could get away with it in
most cases using, e.g., global suffix:

  [cite:@doe 4; with some more text]

Note the example above is not supported yet, but it might be a more
sensible development than

  [cite:@doe {4}, with some more text]

Regards,
-- 
Nicolas Goaziou



Re: Empty headline titles unsupported: Bug?

2021-09-27 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Ihor Radchenko  writes:
>
>> Yet, why not simply alter the headline parser a little bit to support
>> empty titles + tag? Such headlines are used in some of the tests. See
>> the attached patch.
>
> I'm in favor of this change...
>
> Nicolas Goaziou  writes:
>
>> Because, as I wrote, this is ambiguous. You cannot distinguish the
>> following two cases:
>>
>>   * :mytag:
>>   * :myheadline:
>
> ... because I'm not convinced by the above example: I agree this is
> syntactically ambiguous, but as a human I would understand that Org
> would parse
>
>   * :myheadline:
>
> as [beginning of a headline + empty heading + tag].
>
>> So, your patch would only move the problem elsewhere. 
>
> Nicolas, do you strongly feel against this change?  Is moving the
> problem elsewhere is creating more problems I might have overlooked?
>
>> I suggest to not tag emptiness. 
>
> I'd rather allow empty headlines with tags, this seems a useful way
> of filtering/searching contents.
>
> WDYT?

I don't have anything new to bring to this discussion. I don't feel
strongly against anything.

Regards,
-- 
Nicolas Goaziou



Re: org-cite not mentioned in ORG-NEWS for 9.5

2021-09-25 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Hi Bruce,
>
> "Bruce D'Arcus"  writes:
>
>> Pretty sure it just means no documentation has yet been written for
>> it.
>
> We can't release Org 9.5 until someone helps with writing a minimal
> documentation for this important feature.
>
> Any volunteer?

Emmanuel Charpentier (Cc'ed) wrote some nice documentation for this
feature. He might want to chime in.

Regards,
-- 
Nicolas Goaziou



Re: Bug: org-element-map doesn't consider all links in the current buffer [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]

2021-09-25 Thread Nicolas Goaziou
Hello,

Rodrigo Morales  writes:

> This bug report show examples where it is noticeable that
> =org-element-map=, when =link= is the value for the =TYPES= argument,
> doesn't consider all links in the current buffer.

This is not a bug, but your interpretation of the syntax differs from
Org.


There are no links in keywords or properties drawers since those are
plain key-value string pairs.

Regards,
-- 
Nicolas Goaziou



Re: [org-cite] citations in property drawers?

2021-09-15 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> Not all org files are destined for export. I slightly feel users should be
> allowed to put citations in places where it might not make sense in export,
> and that they are responsible for knowing what they are doing.
>
> I am sympathetic to the reality that the second half of that statement is a
> big ask, and that it can lead to confusion. Nothing stops anyone from
> manually typing or pasting a citation into those places though. I would be
> inclined to use the activate function to highlight those that are in places
> that won't export, rather than limit where people can put them using the
> insert mechanism.

Not all Org files are destined for export, yet any syntactically correct
Org file is expected to export without fuss. So, allowing citations
anywhere and then let Org later fail without notice may be asking for
trouble.

I understand the problem, but the solution should not be: "let's pretend
export does not exist".

Regards,
-- 
Nicolas Goaziou



Re: [org-cite] citations in property drawers?

2021-09-15 Thread Nicolas Goaziou
Hello,

Tom Gillespie  writes:

> I could certainly imagine using it, and I don't see any issue with
> doing it from the point of view of the grammar.

That would be a terrible idea. Exporters are not required to handle all
data contained in properties drawers, so this may introduce errors,
e.g., when trying to number citations.

Therefore, to prevent a whole class of issues, data stored in properties
drawer is seen as plain boring text.

> Footnotes can appear in a property drawer without issue,

That's incorrect. Footnotes cannot appear in a property drawer, per
above.

> One question though since I may have missed this in the other
> threads is cite: allowed without the square brackets?

No it isn't. This would conflict with "cite"-type links, if defined.


Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items

2021-08-31 Thread Nicolas Goaziou
Hello,

Anders Johansson  writes:

>> I think a proper fix would be to change `org-duration-from-minutes' so
>> it removes any unknown unit from what is provided from fmt or
>> `org-duration-format', and defaults to (special . h:mm) if nothing is
>> left.
>>
>> WDYT?
>>
> Perhaps. I don't understand `org-duration-from-minutes` well enough to
> change it.

You don't really need to understand it. I suggest using a filter as the
very first step of the function.

> I guess the stripping of unknown units from fmt or
> `org-duration-format` would then have to compare either against
> `org-duration-units` or `org-duration-canonical-units` depending on
> the canonical argument.

Exactly.


Regards,
-- 
Nicolas Goaziou



Re: Bug: unexpected behavior of nesting braces when exporting to LaTeX

2021-08-23 Thread Nicolas Goaziou
Hello,

Chlo De  writes:

> I use Org-mode to take notes. I found that when there are nesting braces 
> inside \emph{ }, \textit{ }, etc. the output is unexpected. The following org 
> text
>
> \emph{{n+1}-a}
> \textit{a{b}c}
>
> will be translated as LaTeX expressions
>
> \emph\{\{n+1\}-a\}
> \textit\{a\{b\}c\}
>
> Can this be fixed?

Org only supports a limited part of the LaTeX syntax as raw syntax. This
is not AucTeX mode!

For complex macros (e.g., with nested braces), you need to use dedicated
environments, as pointed out by Jérémie.

Regards,

-- 
Nicolas Goaziou



Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]

2021-08-11 Thread Nicolas Goaziou
Hello,

Jorge P. de Morais Neto  writes:

> I prepared the patch above to improve the organization of the respective
> manual section.

Applied. Thank you.

>> ** [[info:org#Drawers]]
>>
>> I don't understand the sentence
>>
>>Completion over drawer keywords is also possible using ‘M-’
>>
>> Could give me a simple example of drawer keyword completion?
>
> Sorry for insisting, but can someone give me an example of what the
> manual means by "Completion over drawer keywords"?

  :foo:
  :end:

  :f|

With point at |, M-TAB will complete the line as

 :foo:

> And in this kind of situation, did I do well by attaching the patch to a
> normal reply in the thread, or should I have started a new thread with
> an appropriate subject line?  If so, then please give me details so I do
> it correctly next time.

I think what you did is correct. But the other option would not be the
end of the world either. 

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] ox: Italian smart quotes

2021-08-11 Thread Nicolas Goaziou
Hello,

Davide Peressoni via "General discussions about Org-mode."
 writes:

> From 97a45353d19be98bcf0d94da0d902a025408fa3a Mon Sep 17 00:00:00 2001
> From: DPDmancul 
> Date: Wed, 11 Aug 2021 18:21:55 +0200
> Subject: [PATCH] ox: Italian smart quotes
>
> * ox.el (org-export-smart-quotes-alist): Added support for italian
> smart quotes.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [org-mode] make citation object available to org-cite-make-insert-processor SELECT-STYLE?

2021-08-11 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> So the idea is to present a preview of the style/variant output when
> selecting the style.
>
> Like:
>
> /  (Doe, 2019)
>
> ... or maybe even multiple columns:
>
> /  (Doe, 2019)   \citep
>
> I'm thinking the best way to build this UI is to iterate through
> org-cite-support-styles, and run at least the default export processes
> to create that preview annotation,
>
> As my thinking has evolved (and there's been a lot of discussion on
> this the past week), I see two options:
>
> 1. Generate the previews from the citations at point. This was the
> idea that promoted the suggestion here, since I can't get access to
> that citation data if I use org-cite-make-insert-processor.
>
> 2. Instead, have a standardized example record just for the preview.
> With this approach, the citation context isn't relevant.
>
> As to your question, do any style UIs currently allow you to select a
> style on a new citation before selecting the keys?

I added a citation argument to select-style. Let me know if it works for you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items

2021-08-11 Thread Nicolas Goaziou
Hello,

Anders Johansson  writes:

> org-duration-from-minutes was called with canonical = t, but without
> providing a corresponding format only using the canonical units. This
> broke if the user’s org-duration-format used other than the canonical
> units.

I think a proper fix would be to change `org-duration-from-minutes' so
it removes any unknown unit from what is provided from fmt or
`org-duration-format', and defaults to (special . h:mm) if nothing is
left.

WDYT?

Regards,
-- 
Nicolas Goaziou



Re: citations: rx problems with emacs-26.3

2021-08-11 Thread Nicolas Goaziou
Hello,

Maxim Nikulin  writes:

> Nice. Perhaps `org-cite-biblatex-export-citation' should be fixed in
> a similar way. There is no error yet but compiled file is
> significantly blown up:
>
> -rw-rw-r-- 1 ubuntu ubuntu 13383 Aug  9 02:17 lisp/oc-biblatex.el
> -rw-rw-r-- 1 ubuntu ubuntu 48906 Aug  9 17:06 lisp/oc-biblatex.elc
>
> There are a couple of issues with "make single" for emacs-25.2:
>
> Compiling single /home/ubuntu/org-mode/lisp/oc-basic.el...
>
> In end of data:
> oc-basic.el:772:1:Warning: the function ‘buffer-hash’ is not known to be
> defined.
> Compiling single /home/ubuntu/org-mode/lisp/oc-biblatex.el...
> Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el...
>
> In toplevel form:
> oc-csl.el:90:1:Error: Cannot open load file: No such file or
> directory, org-cite
> Makefile:59: recipe for target 'oc-csl.elc' failed
> make[2]: [oc-csl.elc] Error 1 (ignored)

All fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: citations: rx problems with emacs-26.3

2021-08-11 Thread Nicolas Goaziou
Hello,

Maxim Nikulin  writes:

> On 08/08/2021 03:27, Nicolas Goaziou wrote:
>> Maxim Nikulin writes:
>> 
>>> It seems, rx e.g. in emacs-26.3 does not support all features used in
>>> oc.el and oc-csl.el. Loading an org file using git master, I get
>>> a warning
>>>
>>>> Eager macro-expansion failure: (error "rx form ‘regexp’ requires args 
>>>> satisfying ‘stringp’")
>> Thanks. Could you send the patch again with a proper commit message,
>> using git format-patch?
>
> With the attached patches I do not see warnings any more while org is
> loading. On the other hand I am not an org-cite user,

Applied. Thank you.

> so I am not sure that nothing is broken by these patches.

I'll trust the test suite on this.

Regards,
-- 
Nicolas Goaziou



Re: citations: rx problems with emacs-26.3

2021-08-08 Thread Nicolas Goaziou
Hello,

Maxim Nikulin  writes:

> On 08/08/2021 03:27, Nicolas Goaziou wrote:
>> Maxim Nikulin writes:
>>>
>>> It seems, rx e.g. in emacs-26.3 does not support all features used in
>>> oc.el and oc-csl.el. Loading an org file using git master, I get
>>> a warning
>>>
>>>> Eager macro-expansion failure: (error "rx form ‘regexp’ requires args 
>>>> satisfying ‘stringp’")
>>>
>>>> diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
>> Thanks. Could you send the patch again with a proper commit message,
>> using git format-patch?
>
> I going to do it. For a while, I have noticed another problem with
> a lot of pcase branches in `org-cite-natbib--style-to-command' in and
> my experience is not enough to resolve it. On attempt to
> byte-compile-file
> the following error is reported after significant delay (and CPU fan
> becomes more noisy)
>
> oc-natbib.el:108:9:Error: Bytecode overflow

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: citations: rx problems with emacs-26.3

2021-08-07 Thread Nicolas Goaziou
Hello,

Maxim Nikulin  writes:

> I think citation support is a great feature. (Sorry, I do not work
> with references now, so I can tell nothing concerning implementation
> for org.)
>
> It seems, rx e.g. in emacs-26.3 does not support all features used in
> oc.el and oc-csl.el. Loading an org file using git master, I get
> a warning
>
>> Eager macro-expansion failure: (error "rx form ‘regexp’ requires args 
>> satisfying ‘stringp’")
>
> It looks like (rx (regexp ...)) require namely literal, variables are
> not supported yet. In additional (rx (literal ...)) is not supported
> as well.
>
>> Eager macro-expansion failure: (error "Unknown rx form ‘literal’")
>
> In a couple of places `rx-to-string' likely could be used instead of
> just `rx'. I have no idea yet what could be done with (pcase-let* ((rx 
> ...))) in `org-cite-adjust-note'.
>
>> diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el

Thanks. Could you send the patch again with a proper commit message,
using git format-patch?

Regards,
-- 
Nicolas Goaziou



Re: bug processing non emacs-lisp blocks

2021-08-07 Thread Nicolas Goaziou
Hello,

dmg  writes:

> org-babel-load-file will try to tangle any source block that contains
> the substring emacs-lisp or elisp in their language.
>
> For example, the following code block will be tangled:
>
> #+begin_src emacs-lispDONOT
> (use-package "org-sidebar")
> #+end_src
>
> the following patch fixes that problem. The Regular expression should
> be more stringent, so it does match exactly the string and not a
> substring.

Thank you. I applied an equivalent patch.

Regards,
-- 
Nicolas Goaziou



Re: Bug: invalid example for org-export-define-backend's :menu-entry argument [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

2021-08-07 Thread Nicolas Goaziou
Hello,

Zachary Kanfer  writes:

> Ox.el contains the function org-export-define-backend. One of its
> keyword arguments is :menu-entry. The examples given include
> (https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L1214)
>
> '(?l "Export to LaTeX"
>  (?p "As PDF file" org-latex-export-to-pdf)
>  (?o "As PDF file and open"
>  (lambda (a s v b)
>(if a (org-latex-export-to-pdf t s v b)
>  (org-open-file
>   (org-latex-export-to-pdf nil s v b))
>
> This is invalid for two reasons:
>
> 1. The ?p and ?o elements should be wrapped in an extra layer of
> parentheses. For example, the ?p element should be ((?p "As PDF file"
> org-latex-export-to-pdf)).
> 2. There is an extra parenthesis at the end of the block.

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] ox.el: fix spanish translation for `footnotes'

2021-08-07 Thread Nicolas Goaziou
Hello,

Juan Manuel Macías  writes:

> The Spanish translation for "Footnotes" in `org-export-dictionary' is
> "Nota al pie de página" ("Nota"[="Note"], in the singular form). I think
> it would be more correct "Notas", in the plural form. Attached a small
> patch.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: org-cite and pandoc

2021-08-07 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> By the way, ox-md also fails if there is a #+bibliography
> line.  Removing it allows for the export.  Very strange.

Would you have an ECM? I cannot reproduce it.

Regards,
-- 
Nicolas Goaziou



Re: org-cite-list-bibliography-files

2021-07-30 Thread Nicolas Goaziou
Hello,

Titus von der Malsburg  writes:

> 1. `org-cite-list-bibliography-files' returns the bibliographies
> defined locally and the globally defined bibliographies together.
> I propose to only list the local bibliographies, if defined, and to
> return the global bibliographies otherwise. I think the user needs
> a way to override the global setting if necessary. For example, when
> I work on a manuscript, I’d like to use that manuscript’s dedicated
> bibliography, but ignore my global bibliography. It’s very common to
> work with dedicated bibliographies IME, and the UI of oc-basic doesn’t
> show from which bibliography an entry is coming. So there’s no way to
> reliably select entries from just the dedicated/local bibliography.

As pointed out in this thread, I think using file local variables to set
`org-cite-global-bibliography' to nil is simple and Emacsy enough.

> 2. The oc-basic processor makes citations look like clickable links
> (blue, underlined, mouse pointer changes to finger), but when I click
> on them, nothing happens. I can only follow a references via
> `org-open-at-point'. It would be good to make citations clickable.

Done. Thank you.

> I also suggest allowing users to follow links via C-c C-c which
> currently doesn’t do anything on citations. The other obvious action
> that C-c C-c could trigger would be `org-cite-insert'. Not sure what’s
> better.

Neither. Both actions (follow and insert) already have a top-level
binding. It would be a waste to add C-c C-c to that. We might want to
use it for something different at some point.

Regards,
-- 
Nicolas Goaziou



Re: [org-mode] make citation object available to org-cite-make-insert-processor SELECT-STYLE?

2021-07-29 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> But to do that best and most consistently (next step is CSL, for
> example), I need the citation accessible from there, so I can run the
> export processors to generate the previews.
>
> Could we possibly tweak SELECT-STYLE to take one argument: citation?

When you are inserting a whole new citation, what would be the value?
nil? What would you display then?

Regards,
-- 
Nicolas Goaziou



Re: [BUG] Citations in tables are not exported

2021-07-29 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> It is partially fixed for me. I can put a citation in all these places in a
> cell (and in a caption),
>
> | x  |
>  ^^^
>
> but not here
>
> | x  |
> ^
>
> In case this doesn't render quite right, the cell has two spaces after x,
> and I can insert a citation on the first space, but not the second one (or
> subsequent ones if they exist).

Fixed, too. Thank you.

> It still looks like the citation in a table doesn't export, e.g.
> in
>
> #+caption: in a caption [cite/t:@lin-2021-exper-theor]
> | X [cite/t:@lin-2021-exper-theor] | test  |
>
>
> the citation in the caption is exported (in latex), but not the one in the
> cell.

I cannot reproduce it. Do you still encounter it?

Regards,
-- 
Nicolas Goaziou



Re: [BUG] Citations in tables are not exported

2021-07-29 Thread Nicolas Goaziou
Hello,

Matt Price  writes:

> No doubt this is a bit too broad, though I am not entirely clear on why
> there are any restrictions at all on inserting cites.

There are locations which can break the structure of the document.
Obviously, we can let users shoot themselves in the foot, but, OTOH,
a decent interface should prevent the most obvious issues.

WDYT?

Regards,
-- 
Nicolas Goaziou



Re: [BUG] Citations in tables are not exported

2021-07-29 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> I also see this behavior. I think this should be considered a bug, it is
> pretty common to see citations in a table cell.
>
> Additionally, I cannot insert a citation in a caption that is above a
> table (or a figure), I get
> "user-error: Cannot insert a citation here". That should be considered a
> bug in org-cite--allowed-p  I think. It fails because in the caption the
> context is a table, and it has :post-affiliated item which causes
> org-cite--allowed-p  to return nil.
>
> If I put a citation in the caption anyway, it does seem to get exported
> correctly.

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: virtual-fill mode in mail buffers, with orgalist-mode, prefix is not considered when virtual-fill is on

2021-07-27 Thread Nicolas Goaziou
Hello,

Uwe Brauer  writes:

> Not sure whether this is off topic, but it concerns orgalist-mode:
>
> When I use virtual-fill-mode together with orgalist-mode in mail buffers:  
> When I turn virtual-auto-fill-mode off and auto-fill-mode on, the lists are 
> nicely filled as:
>
>
>
> 1. The first item blab bladnka bladnfkand adnfkaj kjkajdkfj ablkadf
>kj kajldjf adfkjaksdfjl
>
>
> While with auto-fill-mode off and visual-auto-fill-mode on the are displayed 
> as
>
> 1. The first item blab bladnka bladnfkand adnfkaj kjkajdkfj ablkadf 
> kj kajldjf adfkjaksdfjl
>
>
>
> So the prefix is not taken into account. Anybody seeing this and knows
> a solution?

Orgalist mode does not handle virtual indentation. Patches welcome,
however.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] [BUG] Bad fontification in full displayed links

2021-07-27 Thread Nicolas Goaziou
Hello,

Juan Manuel Macías  writes:

> You are right, I think that solution is much simpler. I attach a
> new patch and I have included your name in the commit message, for the
> suggestion. Thanks!

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: Bug: duplicated \texttt in LaTeX export

2021-07-27 Thread Nicolas Goaziou
Hello,

Maxim Nikulin  writes:

> It seems, something goes wrong with LaTeX export at least in git master
>
>  >8 
>
> #+PROPERTY: header-args :eval never-export :exports code :results silent
>
> src_elisp{(delete-dups nil)}
>  8< 
>
> Export as LaTeX buffer:
>
>  \texttt{\texttt{(delete-dups nil)}}
>
> I see no reason why \texttt should be doubled this case. Expectation: e.g.
>
>  \texttt{(delete-dups nil)}

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou



Citations merged!

2021-07-09 Thread Nicolas Goaziou
Hello,

It took years, but citations are now full part of Org syntax.

Thanks to everyone involved over the time!

Now, it needs to be documented, but that will come a bit later.

Regards,
-- 
Nicolas Goaziou



Re: Bug: [PATCH] Use crm for tag completion [9.4.6 (9.4.6-gab9f2a @ /home/ionasal/.emacs.d/elpa/org-9.4.6/)]

2021-07-09 Thread Nicolas Goaziou
Hello,

Allen Li  writes:

> * lisp/org-capture.el (org-capture-fill-template): Changed to use
> completing-read-multiple.
> * lisp/org.el (org-set-tags-command): Changed to use
> completing-read-multiple.
> (org-change-tag-in-region): Changed to use a simple completion table.
> * testing/lisp/test-org.el (test-org/set-tags-command): Fixed tests.
> * etc/ORG-NEWS (Tag completion now uses =completing-read-multiple=):
> Added news.

Applied. Thank you.

I just changed string-join into to good ole mapconcat as the code base
does not use subr-x.el

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Merging tomorrow?

2021-07-08 Thread Nicolas Goaziou
Timothy  writes:

> Lastly, an example of what I’d expect when exporting to ascii (with three
> example syntaxes):
>
> ┌
> │ #+name: sometab
> │ #+caption: Some table
> │ | a | b |
> │ | c | d |
> │ 
> │ Hey, look at [[sometab]]. (or)
> │ Hey, look at [cite:#sometab]. (or)
> │ Hey, look at [ref:sometab].
> └
>
> ┌
> │ ━━
> │  a  b 
> │  c  d 
> │ ━━
> │ Table 1: Some table
> │ 
> │ Hey, look at Table 1.
> └

I'm still lost, sorry.

--8<---cut here---start->8---
#+name: sometab
#+caption: Some table
| a | b |
| c | d |

Hey, look at Table [[sometab]].
--8<---cut here---end--->8---

is already exported as

--8<---cut here---start->8---
━━
 a  b 
 c  d 
━━
Table 1: Some table

Hey, look at Table 1.
--8<---cut here---end--->8---

Could you explain what you would like to see, in addition to what is
already possible?

I think, however, that it is not directly related to citations, unless
you want to be able to somehow link to a cite. Then we may have
a problem, because there is currently no way to name a cite. However, if
that ever makes sense, it is still possible to add a target next to it:

   <<@key>>[cite:@key]



Re: [wip-cite-new] Merging tomorrow?

2021-07-08 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> Why C-c ' and not C-c C-o to be consistent with the rest of org?  For
> me, it seems that in the rest of org, C-c ' is for editing something;
> C-c C-o is for opening/visiting/following.

Good question.

 is "remote editing",  is "follow link".

In this situation, I think

  #+bibliography: somefile.bib

is closer from

  #+include: somefile.org

or

  #+setupfile: config.org

than it is from

  [[file:somefile.org]]

So, I do think this is consistent with the rest of Org, actually.

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-08 Thread Nicolas Goaziou
"Bruce D'Arcus"  writes:

> Just a little thing:
>
> Why is it:
>
> org-cite-basic--complete-style
>
> ... rather than:
>
> org-cite-basic-complete-style
>
> I thought you would want to encourage reuse of that one, in
> particular?

In this situation, the function I want to encourage re-using is
`org-cite-supported-styles'. `org-cite-basic--complete-style' is so
trivial that I didn't bother exporting it.



Re: [wip-cite-new] Quick note about citation insertion

2021-07-08 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> On Wed, Jul 7, 2021 at 6:59 PM Nicolas Goaziou  wrote:
>
>> For a developer, there are now two ways to create an insert processor.
>>
>> 1. If you are happy with the global behaviour of "basic", but want to
>>improve completion, I added the `org-cite-make-insert-processor'
>>tool.
>
> This was very helpful, so I just added a commit making use of it.
>
> https://github.com/bdarcus/bibtex-actions#org-cite
>
> So same org-cite-insert behavior as oc-basic, but using
> bibtex-actions-read for the completion.

This is much better than "basic", indeed! :) Thank you for extending the
soon-to-be-born Org Cite ecosystem.

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Merging tomorrow?

2021-07-08 Thread Nicolas Goaziou
Hello,

Timothy  writes:

> Bruce D'Arcus  writes:
>
>>> wip-cite-new deals with citing from bibliographies, but I don't think it
>>> deals with within-document referencing --- should it?
>
>> 1. Should it?
>> 1. Maybe.
>
> I feel like it would fit. With everything that's been done for
> citations, this feels like it may be a rather minor addition (or at
> least this is what I hope).
>
>> 2. Can it? Could the design be extended to include internal referencing?
>> 2. I think so. You'd just need a way to include internal targets in
>> addition to the citation-references (keys); for illustration,
>> something like [cite:#some-if].
>
> I can't claim to have thought about this that much either, but something
> like [cite:#some-fig] would seem to fit.
>
>> 3. If yes to both, should that hold back merger now?
>> 3. No.
>
> I don't think this should hold up the merge either, but it's relevant in
> the overall nature of the feature and perhaps could be shoehorned in
> following the merge? I feel like this is one small quite simple case and
> most of the thinking required has already been done. I'm not sure
> though, I'd go with whatever Nic's thought are on this.

At this point, I don't have enough understanding of the problem to have
an opinion. IIUC, your example does not even mention citations. How
should it be used, what should be the output in LaTeX, and in UTF-8
export? This is not clear to me.

What can I say however is: if this feature implies to change, or extend,
syntax, then it is /de facto/ a blocker for the merge, and needs to be
sorted out.

Regards,
-- 
Nicolas Goaziou



Re: Bug: tab key no longer bound to org-cycle in commit 565361eb69 [9.4.6 (9.4.6-10-gee652a-elpaplus @ /Users/bartm002/.emacs.d/elpa/org-plus-contrib-20210705/)]

2021-07-08 Thread Nicolas Goaziou
Hello,

Mark Barton  writes:

> So I put back the mapping in org-key.el to map TAB instead of  in my 
> local copy and instead commented out line 185 in outline.el to get TAB to map 
> to org-cycle.
>
> ——snippet from outline.el
> (defvar outline-mode-cycle-map
>   (let ((map (make-sparse-keymap)))
> (let ((tab-binding `(menu-item
>  "" outline-cycle
>  ;; Only takes effect if point is on a heading.
>  :filter ,(lambda (cmd)
> (when (outline-on-heading-p) cmd)
>   (define-key map [tab]   tab-binding)
>   (define-key map (kbd "TAB") tab-binding)
>   (define-key map (kbd "") #'outline-cycle-buffer))
> map)
>   "Keymap used by `outline-mode-map' and `outline-minor-mode-cycle'.")
>
> Does that sound like the right thing to do? If so then I could submit
> it to the Emacs dev list.

There are multiple solutions to this. But, as I wrote, you ought to
answer in the other thread I mentioned, the one that initiated this
change, and probably to Emacs Devel.

Regards,
-- 
Nicolas Goaziou



[wip-cite-new] Merging tomorrow?

2021-07-07 Thread Nicolas Goaziou
Hello,

I think the "wip-cite-new" branch is in good shape now. As
a consequence, I'd like to merge it tomorrow.

It is documented, but the documentation is scattered across the various
"oc" libraries, and some threads in the mailing list. I'll do a summary
here, from a user point of view.

--8<---cut here---start->8---
Basically, in order to use it, you need to first set-up a bibliography,
using one or more "bibliography" keywords.  on such a keyword
visits the related file. Out of the box, Org supports JSON-CSL and
BibTeX (or biblatex) bibliographies.

Then, citations can be inserted with the following syntax:

  [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]

Spaces are meaningful except those after the initial colon and before
the closing bracket.

Every part of the syntax is optional, except the brackets, "cite" and
the colon. Also the citation must contain at least a key. So its minimal
form is:

  [cite:@key]

The "style" part is detailed below, in the part related to export.

Org can insert or edit citations with  (and delete them with
), follow them with , fontify them, and export
them. These four actions (insert, follow, activate, and export) are
called capabilities.  Libraries responsible for these capabilities are
called citation processors.

You can select one citation processor for each capability, independently
on the others, through the following variables:

- org-cite-activate-processor
- org-cite-export-processors
- org-cite-follow-processor
- org-cite-insert-processor

Out of the box, Org provides the "basic" (in "oc-basic.el") processor
for all of these tasks. It also boasts processors dedicated for export:
"csl", "natbib" and "biblatex".

During export, output for citations is controlled by their style, which
is an Org label that the export processor may recognize and associate to
a specific display, or fall-back to a default style (called "nil"). For
example, most processors support "noauthor" and "text" styles. 

Some styles can accept a variant, with the syntax "style/variant".
Again, it's up to the processor to associate it to a specific display.
Common variants include "bare", "caps" or "full".  They also accept
short-hands, like "b", "c" and "f".  Please refer to the export
processors' libraries ("oc-basic.el", "oc-csl.el", …) for more information.

It is possible to define a default style for a whole document (with
"cite_export"), or for all documents (with `org-cite-export-processors').

References are displayed with the "print_bibliography" keyword. It is
possible to add parameters to its value, as some export processors could
make use of them.
--8<---cut here---end--->8---

Please let me know if there are any objections to the merge.

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-07 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> Nicolas - I saw you pushed some changes, per the discussion.

Hey, that was a surprise ! ;)

So, here's an update. Now "oc-basic" provides a reasonable experience
for inserting references in a document. It also supports both CSL and
BibTeX bibliographies. Therefore, it is used as the default insertion
processor.

For a user, selecting another insertion processor is done by customizing
`org-cite-insert-processor' variable.


For a developer, there are now two ways to create an insert processor.

1. If you are happy with the global behaviour of "basic", but want to
   improve completion, I added the `org-cite-make-insert-processor'
   tool.

2. If you also want to change the behaviour, you need to write a new
   function from scratch.

Then you define the processor with either:

  (org-cite-register-processor 'my-insert-proc
:insert (org-cite-make-insert-processor
 #'my-select-key
 #'my-select-style));situation 1

or

  (org-cite-register-processor 'my-insert-proc
   :insert #'my-function)   ;situation 2

> First, my initial thought is the behavior at point is perfect.

Ah!

> Second, what's your intended way one enters a citation with two references?
>
> In selectrum, I:
>
> 1. select one reference with RET
> 2. select another
> 3. C-j to exit
>
> Is that the expected workflow and behavior?

Yes, it is.  You need to enter the empty string to exit.  C-j is the way
to do that on Selectrum.  I don't know about Vertico.

Regards,
-- 
Nicolas Goaziou



Re: Bug: tab key no longer bound to org-cycle in commit 565361eb69 [9.4.6 (9.4.6-10-gee652a-elpaplus @ /Users/bartm002/.emacs.d/elpa/org-plus-contrib-20210705/)]

2021-07-07 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> On Tuesday,  6 Jul 2021 at 18:05, Mark Barton wrote:
>> I normally use C-RET to enter a new headline and then press TAB to
>> make it child headline. Recently it stopped working and I think I have
>> it tracked down to the change that was made last week. I could be
>> missing something that allows “TAB” to work for a kdb binding, but the
>> previous format of "" works.
>
> I've also found TAB no longer moving from cell to cell in tables.  I use
> evil and now TAB (translated from  according to C-h c) is bound to
> evil-jump-forward.  The only change in my environment has been updating
> org.

Binding  is frowned upon, because it has higher priority than TAB,
and also because it doesn't work everywhere, like in terminals.

If TAB doesn't work properly in Org, then something, e.g., a minor mode
(Evil in the second case), is stealing the binding. I guess you have to
reclaim it back.

Please see (and answer there)
<https://orgmode.org/list/00ca1c7b-1e1d-fc91-eef3-dfc29b51b...@daniel-mendler.de/>

Regards,
-- 
Nicolas Goaziou



Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/st

2021-07-05 Thread Nicolas Goaziou
Mohsin Kaleem  writes:

> Which question do you refer to?
> If its reproducing with `emacs -Q` I believe I did?

It's not.

I asked if replacing '(lambda ...) with #'org-latex-compile would work too.



Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/straight/build/org/)]

2021-07-05 Thread Nicolas Goaziou
Hello,

Mohsin Kaleem  writes:

> Hi just following up.

Thanks for the heads up, but you haven't answered my question yet.

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-03 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> On Fri, Jul 2, 2021 at 4:05 PM Nicolas Goaziou  wrote:

>> That's expected. "nil" is the name of the processor's fall-back style,
>> ignoring any inheritance. It is different from the empty style (""),
>> which takes into account inheritance.
>
> Two things:
>
> First, after adding a style, I can't see how to subsequently remove it
> using this interface, to just have "[cite:@key]". Is that possible?

Of course. Just select the empty string instead of an entry. It is done
with C-j on Selectrum and `completing-read-default'. I assume this is
the same on other completion frameworks.

> In my formatting function for OC, which is simpler than your's in some
> ways, I have a named "default" style, with that as the
> ido-completing-read "initial-value", which is then removed if
> selected.
>
> In practice, what that means is if the user is prompted for the style
> but hits return, they select "default", and hence the result is
> "[cite:@key]".

Your "default" is equivalent to my empty string. But one day, an export
processor may use "default" as a name for a different style. Who knows?
Moreover, "default" may be ambiguous: does it mean user's or processor's
default style?

More importantly, we have to deal with the empty string anyway; this is
a valid return value from `completing-read'.

> Second, the "nil" vs "empty" distinction was obviously not immediately
> intuitive to me. I don't have a better name for "nil" ATM though, so
> maybe it will be fine. Hopefully people won't have the need to use it
> much.

Both are necessary. At some point, this will have to be documented.

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-03 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> On Saturday,  3 Jul 2021 at 00:33, Nicolas Goaziou wrote:
>> If you have so many keys, you shouldn't be using Org Cite Basics in the
>> first place!

> I think there's a conceptual misunderstanding here

[...]

> My bibliography database contains thousands of entries, accumulated over
> decades of research.  In a typical paper, however, I will cite 10-30 of
> these.  Finding the actual paper to cite does require being able to
> search on not just the keys.  The keys, these days, are automatically
> generated by the journals often.

My tongue in cheek answer was about the weakness of the Org Cite _Basic_
library. I totally understand your need for a serious completion
mechanism that can handle thousands of entries. I was merely pointing
out that this is not the scope of the demo for the interface I wrote.
I hope, however, that really useful tools will be written from that
interface.

Anyway, I'll try to provide something a little more useful out of the
box, based on your comment and Bruce D'Arcus suggestion.

Sorry for not being clear!

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
"Bruce D'Arcus"  writes:

> On Fri, Jul 2, 2021, 5:48 PM Nicolas Goaziou  wrote:

> Rather than just completing the key, how about something like:
>
> ("title author date" . "key")
>
> E.g. look up against the data, and return the key.

Well, I guess it's possible to do. Patches welcome!
>
> It's hard to remember keys if you have hundreds or thousands.

If you have so many keys, you shouldn't be using Org Cite Basics in the
first place!

>> I am a bit lost. Would you mind explaining what should be
>> extensible/configurable?

> For example, plug in a different completion table or function?

The completion table, if required, and the completion mechanism belong
to the insert function. So, you can plug anything you want.



Re: [wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
"Bruce D'Arcus"  writes:

> BTW, you may already be thinking this, but you may as well add completion
> from the files registered with OC at this point. :-)
>
> Only having the completion table populated with in-document keys won't be
> very useful, particularly in a new document.

The completion table is populated by all the keys in the bibliography.
It is not limited to in-document keys.

> If you do, ideally it would be extensible/configurable.
>
> Or is the latter already the case?

I am a bit lost. Would you mind explaining what should be
extensible/configurable?

> OTOH, IDK how much you feel the need to get everything done before merger,
> or whether some pieces can wait?

I'd like to add support for JSON bibliography in Org Cite Basic first.

I'm also wondering if some integration with pcomplete (M-/) is
warranted. It may not be with an efficient enough insertion function.
Maybe this can wait.

Otherwise, I'm mostly done.

Regards,



Re: [wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> I would not use a prefix arg here. you should just check what is at the
> point, and if it is a citation then append it after the citation at point,
> and if not insert a new one (maybe after moving the point to an appropriate
> place if needed).

Well, currently, if there's a reference at point, the function updates
it, which I think is also a valid behaviour.

On other parts of the citation, the function updates its style. Styling
the citation is probably less important than adding a reference. So
I could use C-u for the style, and append a reference when point is not
on one of them already.

However, I'm not designing a canonical way to handle citations here. Any
library (e.g., Org Ref *hint*) is free to use the :insert property and
provide a different implementation. Then, for example,

  (setq org-cite-insert-processor 'org-ref)

will be enough to have it occupy the  binding :)

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
"Bruce D'Arcus"  writes:

> 1. I don't see a way to add a key to an existing citation. Editing an
> existing key uses completing-read, rather than
> completing-read-multiple (as for a new citation), and places point
> after the existing key means the style editing UI will pop up.

Indeed, there's no way to add a reference to an existing citation.
I admit I didn't think about it. What about appending a reference when
the function is called with C-u?

BTW, there's a reason for `completing-read'. When the function is called
on an existing references, it updates the reference, but preserves
affixes. It would make no sense to insert multiple references.

> 2. If I use CRM to add multiple keys, for reasons I haven't
> determined, I get a "match required" error if I complete the second
> key. I can only get it to work if I hit enter before fully completing
> the key. I don't know if this is just some selectrum oddity/bug or
> not.

I encountered this, too. I think this is a Selectrum bug, because when
I disable it, I can successfully use the UI.

Regards,




Re: [wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
Hello,

"Bruce D'Arcus"  writes:

> Looking good Nicolas.
>
> Just one small thing.
>
> If I run on a citation, I get a list of styles, including "nil".
>
> If I select that, "nil" is added to the citation, so that the result
> is "[cite/nil:@key]".

That's expected. "nil" is the name of the processor's fall-back style,
ignoring any inheritance. It is different from the empty style (""),
which takes into account inheritance.

So, basically, in the following document:

  #+cite_export: biblatex whatever text
  [cite/nil:@doe21]
  [cite:@doe21]

the first citation will use \cite whereas the second one will use
\textcite.

Regards,
-- 
Nicolas Goaziou



[wip-cite-new] Quick note about citation insertion

2021-07-02 Thread Nicolas Goaziou
Hello,

I just added an interface to unify functions responsible for inserting
citations in a buffer. The default binding is .

I also plugged a rather crude function with that interface. In order to
use it, you can evaluate:

  (setq org-cite-insert-processor 'basic)

Internally, this will bind  to `org-cite-basic-insert', which
can insert citations, or edit existing ones, depending on the point.

>From a developer point of view, you can specify two new keywords when
registering a new processor: :insert and :cite-styles. See
`org-cite-register-processor' for details. See also an application in
"oc-basic.el", for example.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Customizify org-babel-fortran-compiler

2021-07-01 Thread Nicolas Goaziou
Hello,

Timothy  writes:

> Thanks for sending in the patch. Seeing it pointed out, this seems like
> a pretty obvious omission. This looks like it should be pretty easy to
> merge :)
>
> Four minor niggles with your commit message:
> + Since `defvar' and `defcustom' are elisp symbols, they should be
>   quoted as such.
> + It's probably better to avoid shorthand like "X -> Y", and write out
>   "Change X to Y" instead.
> + You have included "lisp/" in the commit subject, which isn't needed.
>   Just "ob-fortran.el" or even "ob-fortran" is enough here.
> + Your commit subject goes over 50 chars, which is undesirable.
>
> Here's what I'd recommend:
>
> #+begin_example
> ob-fortran: Use a defcustom for fortran compiler
>
> * lisp/ob-fortran.el (org-babel-fortran-compiler): Change `defvar' to 
> `defcustom'
> so that the fortran compiler is customizable like almost all other org-babel
> compilers.
> #+end_example
>
> This is rather minor though, I mention this mostly as a note for the
> future :)

Thanks.

I went ahead, applied the patch with your recommendation, added
a :package-version keyword, and pushed.

Thanks.

Regards,
-- 
Nicolas Goaziou



Re: [patch] add :url and :doi optional entries for export to BiBTeX

2021-07-01 Thread Nicolas Goaziou
Hello,

Eric S Fraga  writes:

> On Thursday,  1 Jul 2021 at 22:23, Timothy wrote:
>> I've not used Org for exporting to BibTeX, so I don't really know what
>> I'm on about, but is there any particular reason why only some entries
>> have :url ? Other than that, this seems like a fairly straightforward
>> patch.
>
> First of all, it's an optional entry so only exported if present. What
> I did was consider which types of publications would tend to have
> a URL instead of other bibliographic information and only include for
> those where it would likely necessary. For instance, journal articles
> will be given a DOI so a URL is less useful; technical reports,
> however, are likely to be hosted at an institution's web site so a URL
> is likely useful.
>
> But I must admit that I didn't spend much time thinking about which
> ones should have it. I didn't want all of them because I often store
> the URL for a journal article in the org file just for quick access
> but I do not want it exported to BiBTeX as it would be messy and
> superfluous when the paper were cited.
>
> I'm glad the patch seemed straightforward!  Thank you.

Applied. Thanks to both of you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Fix erroneous tangling of blocks

2021-07-01 Thread Nicolas Goaziou
Hello,

Timothy  writes:

> I've just taken a look at your patch and it looks good :) glad to see
> you've also followed the commit message format. I hope this gets merged
> soon.

Applied. Thanks for the patch, and thanks for the review.

Regards,
-- 
Nicolas Goaziou



Re: org-mode-map binds [tab]

2021-07-01 Thread Nicolas Goaziou
Hello,

Daniel Mendler  writes:

> `org-mode-map` binds `[tab]` which is unnecessary and harmful, since it
> takes precendence over bindings of TAB even in keymaps with higher
> precedence.

Thou shalt not have precedence over Org mode!

Fixed.

Thank you!

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Fix timestamp agenda setting global agenda name [9.4.6]

2021-06-30 Thread Nicolas Goaziou
Hello,

Ingo Lohmar  writes:

> Subject: [PATCH] Fix timestamp agenda setting global agenda name
>
> * lisp/org.el (org-follow-timestamp-link): Do not set global agenda name
>
> The tmp value for the agenda buffer name is used in `org-agenda-list'
> to set `org-agenda-buffer-name'.  Wrap the call in a let-binding for
> this symbol (like the agenda dispatcher does), since otherwise it
> inadvertently sets the global value.

Applied.

Thank you!

Regards,
-- 
Nicolas Goaziou



Re: Bug: "before first headline" error when adding clock out note [9.4.6 (9.4.6-dist @ /home/wenlong/org-9.4.6/lisp/)]

2021-06-27 Thread Nicolas Goaziou
Hello,

Dave D  writes:

> It seems the error is caused by function
> org-clock-remove-empty-clock-drawer called by org-clock-out-hook
>
> I have removed that function from the hook for now as a workaround.

I pushed a fix in master.

Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] source blocks mangled when edited

2021-06-27 Thread Nicolas Goaziou
Hello,

Sébastien Miquel  writes:

> Subject: [PATCH] org-src.el: Use `replace-buffer-contents' only for emacs >=
>  27
>
> * lisp/org-src.el: Use `replace-buffer-contents' only for emacs >= 27.
>
> It was introduced in emacs 26.1, but earlier versions made no
> guarantees of correctness.

I tweaked the commit message and applied your patch. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: do not attempt to clean the (no-longer-existent) ./contrib directory

2021-06-26 Thread Nicolas Goaziou
Hello,

Greg Minshall  writes:

> Nicolas,
>
>> Sure. Please go ahead.
>
> ahead and went. cheers, Greg

Oops, this one had almost fallen through the cracks! Applied. Thank you
>

Regards,
-- 
Nicolas Goaziou



Re: [wip-cite-new] Where is the development branch ?

2021-06-26 Thread Nicolas Goaziou
Hello,

Emmanuel Charpentier  writes:

> I wanted to test the (new|future) citation abilities of =Org= ; I
> tested what is available in =citeproc-org= with the =org-ref} syntax
> the latter supports.
>
> However, I also wanted to test what is available with the "new" syntax
> planned for introduction in =Org=.

Great!

> According to
> https://github.com/andras-simonyi/citeproc-org#org-mode-citations-and-bibliography-using-the-wip-cite-syntax
> , this is only available on  the  =wip-cite= development branch.>
> However, my freshly updated git clone
> (of https://code.orgmode.org/bzg/org-mode.git ) doesn't have such a
> branch.

The branch is "wip-cite-new".

> Where should I get this code ?

For example, here:

 https://code.orgmode.org/bzg/org-mode/src/wip-cite-new

> Related question : is there an ETA of these new abilities in =Org= ?

I would appreciate some alpha-testing first, but I would say the code is
already good enough for inclusion at this point. I.e., there are
a couple of points open for discussion, but no blocker.

Please let me know how it goes!

Regards,
-- 
Nicolas Goaziou



Re: [SOLVED] (kinda) Calendar vs. org-agenda exit

2021-06-24 Thread Nicolas Goaziou
Hello,

Stephen Berman  writes:

> Yeah, the next time Org is merged to the Emacs master branch, forcing me
> to first stash and then reapply my patch locally, I'll ask if anyone
> objects to the patch being committed to master.

Sure, go ahead.

Regards,
-- 
Nicolas Goaziou



  1   2   3   4   5   6   7   8   9   10   >