Re: Bug: Add an option for org-html-self-link-headlines to add an anchor-link instead of making the headline a link. [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-

[Timothy]

Ihor Radchenko  writes:

> Vladimir Nikishkin  writes:
>
>> Would it be possible to, instead, add a small link, with the same href,
>> and the visible part of something short, such as (#) or (*) hear the
>> headline.
>
> This sounds useful. An example of implementation is
> https://tecosaur.github.io/emacs-config/config.html
>
> Timothy, would you be interested to prepare the patch out of your
> config?

If there's sufficient interest, I'd be happy to cook something up.
I'm not sure it's always desirable though, see:
https://tecosaur.github.io/emacs-config/config.html#header-anchors
perhaps a boolean var to control it would also be worth adding.

--
Timothy.

Re: Problem inserting meeting in agenda using "pm" time indicators

[Ihor Radchenko]

Eric S Fraga  writes:
> When I try this now, with org up to date from git, I get this backtrace:
>
> ,
> | Debugger entered--Lisp error: (error "Invalid duration format: \"3pm\"")

Confirmed

Re: Bug: org-table-clean-line may not return only | and space [9.4.4 (release_9.4.4 @ /home/tbb/code/emacs/emacs/lisp/org/)] [9.4.4 (release_9.4.4 @ /home/tbb/code/emacs/emacs/lisp/org/)]

[Ihor Radchenko]

Mauro Aranda  writes:

> 5. I expected to get a clean row:
> Here is a table:
> |   |   |
> | Data1 | Data2 |
>
> but I got:
> Here is a table:
> |   | Data2 |
> | Data1 | Data2 |

Confirmed

Re: Bug: Add an option for org-html-self-link-headlines to add an anchor-link instead of making the headline a link. [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-

[Ihor Radchenko]

Vladimir Nikishkin  writes:

> Would it be possible to, instead, add a small link, with the same href,
> and the visible part of something short, such as (#) or (*) hear the
> headline.

This sounds useful. An example of implementation is
https://tecosaur.github.io/emacs-config/config.html

Timothy, would you be interested to prepare the patch out of your
config?

Best,
Ihor

Re: HTML export uses anchor ids which change on every export

[Timothy]

Tim Cross  writes:

> Timothy  writes:
>
>> On this, would you have any interested in going back to that thread
>> about IDs generated based on the headings? IIRC it petered out more that
>> reached a conclusion.
>
> I thought the conclusion was that if you wanted link stability, use
> publish rather than export?

No conclusion on the viability of my approach being modified a bit then
integrated into Org.

--
Timothy

Re: Empty headline titles unsupported: Bug?

[Ihor Radchenko]

Tom Gillespie  writes:

> Hi Ihor,
> Yes, happy to put my test cases into the org element cases and
> visa versa.

Patches welcome ;)

Re: Could habits appear in the correspondent hour in org-agenda?

[Ihor Radchenko]

Ypo  writes:

> Hi! Thanks for answering. It was just a thought. Habits appear like this 
> (not sure how images can be attached in the mail list):
>
> borrar-1
>
> I thought it would be interesting to have the option to show them like this:
>
> borrar-2
>
> Thanks for your interest

You can do it simply by changing sorting strategy in agenda. By default,
org-agenda-sorting-strategy is

((agenda habit-down time-up priority-down category-keep)
 (todo priority-down category-keep)
 (tags priority-down category-keep)
 (search category-keep))

You can see that for agenda `habit-down' is considered first in the
sorting order. That makes sense if you want all the habits to be grouped
together. If you prefer the habits to honour scheduled time ordering,
you simply swap `habit-down' and `time-up' in the sorting strategy:

(setq org-agenda-sorting-strategy '((agenda time-up habit-down priority-down 
category-keep)
(todo priority-down category-keep)
(tags priority-down category-keep)
(search category-keep)))

Best,
Ihor

Bug: Reclocking errors out if org-log-note-clock-out is t [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]

[Jorge P. de Morais Neto]

org-log-note-clock-out--bug.el
Description: Elisp to reproduce the bug
Hi.  I use Emacs from Guix---package emacs-next installed from Git
master (through --with-branch=emacs-next=master) and updated weekly.
Org is also from Guix: packages emacs-org{,-contrib,-drill,-pdftools}

To reproduce the bug, save the attached file¹ then invoke:
emacs -q -l /PATH/TO/org-log-note-clock-out--bug.el --batch

- Expected behavior: Org should clock in the first heading, then clock
  out from it, prompt for a note, and clock in the second heading (in
  batch mode, Emacs should print some clocking messages and then exit
  successfully).
- What happens: Org errors out:
  user-error: Before first headline at position 164 in buffer *Org Note*

I stepped through the code and verified the error is triggered at line
1726 on file org-clock.el.  This is the form
(org-back-to-heading t)
on function `org-clock-remove-empty-clock-drawer'.  That function runs
as a hook because of line 1717 on file `org-clock.el':
(run-hooks 'org-clock-out-hook)
on function `org-clock-out'.

Then using git-bisect, I have determined the bug was introduced on
commit c670379adfbdc4883d3cfa230289fd2829993265.  I am sorry for not
providing a patch.

As a temporary workaround, I have erased my customization of
`org-log-note-clock-out'.

Regards

¹ Do you prefer this kind of small file to be attached to the mail
message as I have done here or should I have included it in the mail
body?

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ 
/gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)
-- 
-  "In Support of Richard Stallman"
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: 
- If an email of mine arrives at your spam box, please notify me.

Re: Bug: Reclocking errors out if org-log-note-clock-out is t [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]

[Jorge P . de Morais Neto]

Hi.  I continue below:

Em [2021-05-29 sáb 21:53:47-0300], Jorge P. de Morais Neto escreveu:

> I stepped through the code and verified the error is triggered at line
> 1726 on file org-clock.el.  This is the form
> (org-back-to-heading t)
> on function `org-clock-remove-empty-clock-drawer'.  That function runs
> as a hook because of line 1717 on file `org-clock.el':
> (run-hooks 'org-clock-out-hook)
> on function `org-clock-out'.

For the record: I don't remember why I couldn't get a clear backtrace
and resorted to stepping through the code until I found the error; but I
am indeed aware the stepping is unnecessary in a case like this.

Regards

-- 
-  "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

Re: Empty headline titles unsupported: Bug?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>> Testing the usefulness of extensions to the grammar before they're added
>> to the grammar..?
>
> For simple cases, there is org-element-update-syntax. Otherwise, you
> will probably better use the usual patch/new feature workflow and modify
> the parsers directly.

Thanks
-- 
David Masterson

Re: HTML export uses anchor ids which change on every export

[Tim Cross]

Timothy  writes:

> Nicolas Goaziou  writes:
>
>> No, for public links, CUSTOM_ID is the only sane way to handle this.
>> Even "sec-2" could betray you if you slightly modify the document.
>
> Hi Nicolas,
>
> On this, would you have any interested in going back to that thread
> about IDs generated based on the headings? IIRC it petered out more that
> reached a conclusion.

I thought the conclusion was that if you wanted link stability, use
publish rather than export?

-- 
Tim Cross

Re: Smart quotes not working correctly with single quotes

[Andreas Gösele]

Hi,

thanks to Albert for pointing me to pandoc-quotes.lua.

It doesn't take care of apostrophes so I wrote my own very simple pandoc
lua filter:

 text = require 'text'
 function Str (s)
   s.text = pandoc.pipe("sed", {"-e","s/'/’/"}, s.text)
   return s
 end

Together with pandoc-quotes.lua and "-M lang=de" this gives the desired
result for odt and html.

For latex there was no problem with the apostrophes, but for some reason
(I don't understand) pandoc-quotes.lua with lang=de translates closing
quotes into "``" and "`" instead of "“" and "‘". (The opening quotes are
correct and in pandoc-quotes.lua the "de" entry correctly has "“" and
"‘".) This can lead to something like "```" if inner quotes are
immediately followed by outer quotes which LaTeX translates to "“‘"
instead of "‘“".

To solve this I created a meta file with:

---
quot-marks:
- „
- ​“
- ‚
- ‘
...

(The important thing being that there is a unicode "ZERO WIDTH SPACE"
(U+200B) in front of the second entry.)

I also put \DeclareUnicodeCharacter{200B}{{\hskip 0pt}} into
default.latex.

Using the meta-file with pandoc-quotes.lua and "-V lang=de" leads to
correctly nested quotes also for latex.

Thanks again to everybody!

Andreas

Andreas Gösele  writes:

> Albert Krewinkel  writes:
>
>> Andreas Gösele  writes:
>>
>>> [...] I tried to convert the LaTeX document with pandoc, tex4h and
>>> latex2html to odt and html but none of them produces the correct
>>> output.
>>>
>>> So I'm wondering whether there is any way to make org export to
>>> recognize single quotes also outside from double quote. It should be
>>> possible as inner quotes is not the only use of simple quotes.
>>
>> I apologize for the non-Emacs solution, but you can use pandoc in
>> combination with the following Lua filter to get the desired result:
>> https://github.com/pandoc/lua-filters/tree/master/pandoc-quotes.lua
>> For LaTeX output, you can also pass -Vcsquotes as a parameter to force
>> pandoc to make use of the csquotes package. Both should give you the
>> desired results.
>
> Thanks for the suggestion. I would be happy to use pandoc.
>
> I tried it and it works well for quotes (double and single). But the
> apostrophe only is correctly treated if I convert to LaTeX/PDF. (That's
> because LaTeX transforms the "typewriter apostrophe" into the correct
> typographic apostrophe.)
>
> From:
>
>  #+LANGUAGE: de
>  #+OPTIONS: ':t
>
>  #+OPTIONS: toc:nil
>  It's a 'test'.
>
> I get for html/odt:
>
>  It's a ‚test‘.
>
> But I should get:
>
>  It’s a ‚test‘.
>
> Directly using the org export I get:
>
>  It’s a ’test’.
>
> So with pandoc and the Lua filter the single quotes are correct, with
> the direct export from org the apostrophe is correct.
>
> Is there a way with pandoc to get correct quotes and apostrophes?
>
> Thanks again!
>
> Andreas

Re: [BUG] org-compile-prefix-format regexp change breaks eval forms [9.4.6 (9.4.6-gf72a65)]

[Radon Rosborough]

If you insert the format string into a temporary buffer, then the `read'
function will read up to the closing parenthesis and update point
accordingly. That would be a foolproof way to handle all possible Lisp
forms: use a regexp to find the start, and then use `read' to find the end.
Then proceed with regexp matching, and repeat like that.

Re: Question Regarding Yasnippet With Org Mode (Emacs 27.2)

[Samuel Banya]

Just wanted to update this thread in that the following DID resolve my issue 
with my Yasnippet template which overrides the default " Samuel Banya writes:
> > Do you think that maybe changing the setting you had mentioned before, 
> > 'org-src-tab-acts-natively' to false (aka nil or '0' (zero) value) via 
> > a change in my configuration would make this error not happen within 
> > Org-Mode in that case?
> 
> Yes, that should work. I have not tested it though.
> 
> Regards,
> 
> -- 
> Sébastien Miquel
> 
> 

Re: [kisara.moe] 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/)]

[Nicolas Goaziou]

Hello,

mohsin kaleem  writes:

> I've been trying to get async-export setup for the past day and I've
> found it keeps failing due to an unexpected # in the compilation script
> generated by org-export.
>
> After doing a little debugging I found the script contained
> ~(funcall '# 
> "foo.tex")~
> so at some point in the export org-mode is including an evaluated lambda
> when a quoted one is required.

Your bug sounds plausible, but I cannot reproduce it.

> -  (lambda (file) (org-latex-compile file)
> +  `(lambda (file) (org-latex-compile file)

Anyhow, would #'org-latex-compile fix the issue, too?

Regards,
-- 
Nicolas Goaziou

Re: have =make cleanall= remove .texi files in doc/

[Nicolas Goaziou]

Hello,

Greg Minshall  writes:

> hi.  neither =make clean= nor =make cleanall= remove the two .texi files
> built (by, e.g., =make info=) in the doc subdirectory.  this patch
> removes those files with =make cleanall=.  i wasn't sure which to use,
> but it sort of looked like =cleanall= might be the place.

Applied. Thank you.

> i also noticed that =make cleanall= invokes =find= on =./contrib=, which
> no longer (i assume) exists so =find= complains (which is logged, but
> then ignored, by =make=).  i'm happy to do a patch for that (though it
> would be, presumably, as trivial as this one).

Sure. Please go ahead.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] ox-latex.el/org-latex--make-option-string: Surround option string with braces if it includes brackets

[Nicolas Goaziou]

Hello,

Markus Huber  writes:

> lisp/ox-latex.el (`org-latex--make-option-string'): If `value' of a `pair' 
> from `options' contains a bracket
> the whole `value' is surrounded by braces.
>
> In case of LaTeX export using listings the dialect of a language (e.g. 
> [LaTeX]TeX) is surrounded by brackets. For inline
> source blocks all options end as optional argument to \lstinline between 
> brackets which breaks the LaTeX parser.
> TINYCHANGE

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block

[Nicolas Goaziou]

Hello,

Juan Manuel Macías  writes:

> I'm sorry, it's my fault. It's already fixed. I think the patch attached
> here should apply well...

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> Oh wait, I just realized citeproc-el already has a parameter for
> "caps" (which I hadn't realized).
>
> - "bare" -> "suppress-affixes" parameter
> - "caps" -> "capitalize-first"
>
> Right?
>
> So that would allows support for:
>
> - "bare"
> - "caps"
> - "bare-caps"

Correct. I added support for the three style variants.

Re: HTML export uses anchor ids which change on every export

[Timothy]

Nicolas Goaziou  writes:

> No, for public links, CUSTOM_ID is the only sane way to handle this.
> Even "sec-2" could betray you if you slightly modify the document.

Hi Nicolas,

On this, would you have any interested in going back to that thread
about IDs generated based on the headings? IIRC it petered out more that
reached a conclusion.

--
Timothy.

Re: HTML export uses anchor ids which change on every export

[Nicolas Goaziou]

Hello,

sba...@catern.com writes:

> HTML export wraps headlines in anchor tags with IDs, so that they can be
> linked by suffixing #[anchor-tag-ID] to the URL.
>
> HTML export used to use anchor IDs like "sec-2" for the second headline,
> but at some point it switched to generated IDs like "org7ffb324", which
> change on every re-export.
>
> This means anchor-links on external sites (that is, links which link to
> a specific section of an org file) break every time an org file is
> re-exported to HTML. The old style of anchor IDs would break URLs when
> sections moved around, but at least it wouldn't break on every
> re-export!
>
> This makes org much less useful for typical web publishing use cases.
>
> This can be worked around by setting CUSTOM_ID for every headline, which
> will override the anchor id used, but I think it was much better when it
> just worked by default...
>
> It looks like this was changed in commit
> 459033265295723cbfb0fccb3577acbfdc9d0285
> "Export back-ends: Use `org-export-get-reference'"
>
> Perhaps this functionality (of generating anchor IDs based on the
> section number) could be added back in?

No, for public links, CUSTOM_ID is the only sane way to handle this.
Even "sec-2" could betray you if you slightly modify the document.

Regards,

-- 
Nicolas Goaziou

Re: Empty headline titles unsupported: Bug?

[Tom Gillespie]

Hi Ihor,
Yes, happy to put my test cases into the org element cases and
visa versa. My long term plan is to come up with a set of test cases
that are unambiguous and potentially ambiguous so that we can
determine the expected behavior in those cases, so this is a great
first step. Best,
Tom

HTML export uses anchor ids which change on every export

[sbaugh]

HTML export wraps headlines in anchor tags with IDs, so that they can be
linked by suffixing #[anchor-tag-ID] to the URL.

HTML export used to use anchor IDs like "sec-2" for the second headline,
but at some point it switched to generated IDs like "org7ffb324", which
change on every re-export.

This means anchor-links on external sites (that is, links which link to
a specific section of an org file) break every time an org file is
re-exported to HTML. The old style of anchor IDs would break URLs when
sections moved around, but at least it wouldn't break on every
re-export!

This makes org much less useful for typical web publishing use cases.

This can be worked around by setting CUSTOM_ID for every headline, which
will override the anchor id used, but I think it was much better when it
just worked by default...

It looks like this was changed in commit
459033265295723cbfb0fccb3577acbfdc9d0285
"Export back-ends: Use `org-export-get-reference'"

Perhaps this functionality (of generating anchor IDs based on the
section number) could be added back in?

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 1:25 PM Bruce D'Arcus  wrote:
>
> On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou  
> wrote:

> > We dropped variant inheritance some time ago already, when the suggested
> > syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> > totally different from Org Cite POV. I'd rather not re-introduce this.
>
> Oh wait, I just realized citeproc-el already has a parameter for
> "caps" (which I hadn't realized).
>
> - "bare" -> "suppress-affixes" parameter
> - "caps" -> "capitalize-first"
>
> Right?
>
> So that would allows support for:
>
> - "bare"
> - "caps"
> - "bare-caps"
>
> So if he adds an equivalent of the "full" parameter, that could extend
> the sub-styles support in oc-csl?

I added an issue for this at the citeproc-el issue tracker:

https://github.com/andras-simonyi/citeproc-el/issues/16

Note that one key difference with oc-csl is the variants are
configured with individual parameters, while LaTeX uses commands.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > Right now, citeproc-el, and hence also oc-csl, only supports the "bare" 
> > variant.
> >
> > Would it be feasible, and make sense, to fall back all "bare" variants
> > to "bare" for now?
> >
> > So this:
> >
> > [cite//bare-caps:@latexcompanion]
> >
> > ... would render as:
> >
> > Doe 2019
>
> We dropped variant inheritance some time ago already, when the suggested
> syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> totally different from Org Cite POV. I'd rather not re-introduce this.

Oh wait, I just realized citeproc-el already has a parameter for
"caps" (which I hadn't realized).

- "bare" -> "suppress-affixes" parameter
- "caps" -> "capitalize-first"

Right?

So that would allows support for:

- "bare"
- "caps"
- "bare-caps"

So if he adds an equivalent of the "full" parameter, that could extend
the sub-styles support in oc-csl?

> Maybe "bare" need to be promoted as a full-fledged style, so "bare/caps"
> could fallback to "bare". I don't know.

I thought of that too, but it won't work, because "bare" applies to
multiple styles.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> Right now, citeproc-el, and hence also oc-csl, only supports the "bare" 
> variant.
>
> Would it be feasible, and make sense, to fall back all "bare" variants
> to "bare" for now?
>
> So this:
>
> [cite//bare-caps:@latexcompanion]
>
> ... would render as:
>
> Doe 2019

We dropped variant inheritance some time ago already, when the suggested
syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
totally different from Org Cite POV. I'd rather not re-introduce this.

Maybe "bare" need to be promoted as a full-fledged style, so "bare/caps"
could fallback to "bare". I don't know.

Regards,

Re: [org-cite, oc-csl] print_bibliography options

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> So two duplicate lists.
>
> Does that clarify?

Indeed, thanks.

> The other common case I am familiar with is a bibliography per section
> of a document.
>
> It may not be practical to do anything other than current behavior,
> but I was hoping some biblatex experts might have some thoughts.
>
> And, of course, wanting to flag this for András to think about, since
> ideally citeproc-el would support this.

OK. I'll let experts discuss the topic.

Regards,

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Fri, May 28, 2021 at 4:31 PM András Simonyi  
> wrote:
>
>> Maybe instead of a full alist mapping backends to citation processors
>> we could have only options to declare a separate processor for
>> latex-based backends and another for non-latex ones?
>
> This would go a long way, and is probably all that's necessary.
>
> Really "latex" is the unique output mode here.

But one may want to use a different processor for, say, beamer and
regular latex. Both are "latex" based. Worse, all custom back-ends
derived from "latex" are bound to use the same processor.

Here's another proposal:

`org-cite-export-processor' is now an alist, where keys are export
back-ends or t, which is the default key.

  '((latex biblatex bibstyle citestyle)
(beamer natbib nil nil)
(my-latex natbib bibstyle)
(t csl nil nil))

The selected processor is the one associated to the back-ends closest to
the current one used for export, by `org-export-derived-backend-p'
order. So if `my-other-latex' is derived from beamer, it will use
(natbib nil nil).

OTOH, I suggest to stick to a single "cite_export" keyword, which
overrides any selected processor above. IOW

   #+cite_export: basic

will use basic whatever the current export back-end is.

In practice, I think it is sufficient. The only case where it may be
limiting is if you need to export with two different back-ends with two
processors different from those set in `org-cite-export-processor'. But
in that situation, I think swapping the cite_export keyword is
acceptable.

So overall, I think it is a good compromise between simplicity and
power.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: [org-cite, oc-csl] print_bibliography options

[Bruce D'Arcus]

On Sat, May 29, 2021 at 11:15 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> >> Bibliography is printed using "\printbibliography" command.  Additional
> >> options may be passed to it through a property list attached to the
> >> "print_bibliography" keyword.  E.g.,
> >>
> >>#+print_bibliography: :section 2 :heading subbibliography
>
> > I don't believe citeproc-el currently supports any of these features,
> > and it looks like the citeproc-el API doesn't even have an optional
> > parameter to put details like these.
> >
> > As a consequence, if one adds an example like the above, so that one
> > has two print_bibliography lines, one will get two, duplicate
> > bibliography lists outside of oc-biblatex.
>
> I don't understand how you reach that consequence… If the citation
> processor does not understand the properties, it simply ignores them,
> but obeys to "print_bibliography" directive anyhow.
>
> Have you tried it? I'm not sure to understand your concern.

Yes.

I think we're saying the same thing, but maybe I need to clarify the
implications better?

See below.

Let me illustrate with a full example, where the @einstein entry has a
"keyword" field of "primary."

The use case is a user wanting a bibliography with two sections, which
is a common case for this feature.

Note that I am unsure of the exact invocation to achieve this with
biblatex (as in, it's probably wrong), but I don't think that matters
to illustrate the point.

>
#+language: en
#+bibliography: test.bib
#+cite_export: csl

1. simple: [cite:@latexcompanion]
2. primary source: [cite:@einstein]
3. affixes: [cite/text:see @latexcompanion chapter 2 p.23]
4. quote, punctuation: “my quote” [cite/text/caps:@latexcompanion].

* Bibliography
** Primary Sources
#+print_bibliography: :keyword primary :title "Primary Sources"
** Secondary Sources
#+print_bibliography: :title "Secondary Source"
<

Here's the output from oc-csl:

>
1. simple: (Goossens, Mittelbach, and Samarin 1993)
2. primary source: (Einstein 1905)
3. affixes: (see Goossens, Mittelbach, and Samarin 1993, chaps. 2 p.23)
4. quote, punctuation: “my quote” (Goossens, Mittelbach, and Samarin
   1993).


1 Bibliography
══

1.1 Primary Sources
───

  Einstein, Albert. 1905. “Zur Elektrodynamik Bewegter Körper. (German)
  [on the Electrodynamics of Moving Bodies].” /Annalen Der Physik/ 322
  (10):891–921.

  Goossens, Michel, Frank Mittelbach, and Alexander Samarin. 1993. /The
  LaTeX Companion/. Reading, Massachusetts: Addison-Wesley.


1.2 Secondary Sources
─

  Einstein, Albert. 1905. “Zur Elektrodynamik Bewegter Körper. (German)
  [on the Electrodynamics of Moving Bodies].” /Annalen Der Physik/ 322
  (10):891–921.

  Goossens, Michel, Frank Mittelbach, and Alexander Samarin. 1993. /The
  LaTeX Companion/. Reading, Massachusetts: Addison-Wesley.
<

So two duplicate lists.

Does that clarify?

The other common case I am familiar with is a bibliography per section
of a document.

It may not be practical to do anything other than current behavior,
but I was hoping some biblatex experts might have some thoughts.

And, of course, wanting to flag this for András to think about, since
ideally citeproc-el would support this.

Bruce

Re: [org-cite, oc-csl] print_bibliography options

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

>> Bibliography is printed using "\printbibliography" command.  Additional
>> options may be passed to it through a property list attached to the
>> "print_bibliography" keyword.  E.g.,
>>
>>#+print_bibliography: :section 2 :heading subbibliography

> I don't believe citeproc-el currently supports any of these features,
> and it looks like the citeproc-el API doesn't even have an optional
> parameter to put details like these.
>
> As a consequence, if one adds an example like the above, so that one
> has two print_bibliography lines, one will get two, duplicate
> bibliography lists outside of oc-biblatex.

I don't understand how you reach that consequence… If the citation
processor does not understand the properties, it simply ignores them,
but obeys to "print_bibliography" directive anyhow.

Have you tried it? I'm not sure to understand your concern.

Regards,
-- 
Nicolas Goaziou

[org-cite, oc-csl] print_bibliography options

[Bruce D'Arcus]

Nicolas, András,

I wanted to pull this example out from oc-biblatex for consideration in oc-csl:

On Tue, May 18, 2021 at 11:45 AM Nicolas Goaziou  wrote:

> Bibliography is printed using "\printbibliography" command.  Additional
> options may be passed to it through a property list attached to the
> "print_bibliography" keyword.  E.g.,
>
>#+print_bibliography: :section 2 :heading subbibliography
>
> Values including spaces must be surrounded with double quotes.  If you need
> to use a key multiple times, you can separate its values with commas, but
> without any space in-between:
>
>#+print_bibliography: :keyword abc,xyz :title "Primary Sources"

This is a great addition for that module, but I'm wondering what to do
with documents written using this in oc-csl.

I don't believe citeproc-el currently supports any of these features,
and it looks like the citeproc-el API doesn't even have an optional
parameter to put details like these.

As a consequence, if one adds an example like the above, so that one
has two print_bibliography lines, one will get two, duplicate
bibliography lists outside of oc-biblatex.

So two questions:

1. Do you have any interest in adding support for this in citeproc-el
at some point András?
2. Is the current behavior acceptable? If not, any better options? I'm
not sure there is, but thought I'd ask anyway. Biblatex users familiar
with this feature might have some ideas on this?

I guess I just want to call your attention to this, in the event you
had any thoughts on if and how to support this going forward.

Bruce

Re: Passing a variable into an R source block.

[Roger Mason]

Hello Charles & William,

Berry, Charles writes:

> data.frame($data) is not valid R syntax. If you are new to R doing some 
> tutorials will help.
>
> I suggest you use C-c C-v C-v (org-babel-expand-src-block) to see what the R 
> code is and debug the result given in the the *Org Babel Preview...* buffer.

You are correct, my R skills are _very_ rusty.  I did not know of
org-babel-expand-src-block, thanks for the pointer.  Very useful.

William Denton writes:

> The Org table is passed in to R as a data.frame, so all you need is this at 
> the 
> start (with stringr loaded in previously):

Thanks William, that got me going in the right direction.

Roger

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 3:51 AM Stefan Nobis  wrote:
>
> Nicolas Goaziou  writes:
>
> > By default, no export processor is selected. All citations are
> > removed from output, and print_bibliography keywords, ignored.
>
> As I'm coming from LaTeX and have been bitten more than once by
> missing citations in the output (which is solved far better today by
> biblatex), I would say this is not a very good default.
>
> Citations should never be removed (or only with quite some effort). If
> you publish a text where citations have been removed by accident,
> that's asking for much trouble.
>
> Therefore I would suggest to set some sensible default that at least
> does not remove citations. For example a simple ASCII export with
> number or author-year style could be the default citation export for
> all back-ends. For quite some users (e.g. non-academic, internal
> white-papers etc.) this may be also a "good enough" solution, so they
> get easy citation support OOTB.
>
> Everyone else would choose some more sophisticated back-end.
>
> > It could be possible to change `org-cite-export-processor' so it
> > becomes an alist where you can associate back-ends to processors.
> > But I can't see how to transpose it nicely to cite_export keyword.
>
> What about "cite_export" for a single/default export engine and
> "cite_export_" (with "" something like "html",
> "latex", "md", etc.) for overriding the citation exporter for the
> given back-end, e.g.
>
> cite_export ascii
> cite_export_latex biblatex chicago
> cite_export_html csl "some style"
>
> (I forgot about the correct syntax for cite_export, so just a really
> rough sketch to illustrate the idea).
>
> Would that be feasible?

This is similar to what Andras was suggesting, though his suggestion
is even simpler, because it would only have one for latex; so just
default and latex.

I think that's all we need.

> > I'm not convinced this would be an improvement either. For example,
> > you may want to use two different processors with the same back-end.
>
> I'm not sure if this is true for many back-ends. Currently, I would
> assume that this is only the case for the LaTeX back-end (e.g.
> preparing a paper for different journals with different citations
> requirements). But in this case LaTeX has already quite some tools
> that could be utilized. All the different kinds of citation commands
> are there to be able to easily switch styles for the whole document
> (within a single back-end).

To review, for people that may not be that familiar with CSL, in particular.

LaTeX does all that, with the major limitation that it doesn't do
HTML, docx, rtf, etc.

CSL with citeproc-el does LaTeX (completely bypassing
bibtex/biblatex), and plain text and HTML, and implementations like
pandoc, also do docs, rtf, etc.

So even LaTeX users would likely still want to have oc-csl as their
default processor, for when they want to export to HTML or plain text.

Some, or even many, LaTeX users would prefer to use oc-natib or
oc-biblatex for primary latex export though.

I'm not convinced it's necessary or useful to separately configure for
plain text vs HTML.

Bruce

Re: Empty headline titles unsupported: Bug?

[Ihor Radchenko]

David Masterson  writes:
> Testing the usefulness of extensions to the grammar before they're added
> to the grammar..?

For simple cases, there is org-element-update-syntax. Otherwise, you
will probably better use the usual patch/new feature workflow and modify
the parsers directly.

Best,
Ihor

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Fri, May 28, 2021 at 4:31 PM András Simonyi  wrote:

> Maybe instead of a full alist mapping backends to citation processors
> we could have only options to declare a separate processor for
> latex-based backends and another for non-latex ones?

This would go a long way, and is probably all that's necessary.

Really "latex" is the unique output mode here.

Bruce

[bug] org-agenda-set-tags does not append tags to headline but at cursor

[Jakob Schöttl]

Org mode version: 9.4.6
... but the problem is older:

Reproduce:

1. Open org-agenda
2. Open a task from the agenda in the other buffer (i.e. the org file)
3. In the org file, move the cursor away from the task's headline
4. Focus the same task in the org-agenda again
5. Press C-c C-q (org-agenda-set-tags) and select some tags

The tags are not appended to the task's headline but to the line the 
cursor was.


Example:

I'm in org-agenda and press C-c C-q, select "test" as tag. The result is:

** TODO Update libxxx on AUR
SCHEDULED: <2020-09-20 Sun>  :test:

Re: Org-capture %K "Link to the currently clocked task" link with id?

[Ihor Radchenko]

Nathaniel W Griswold  writes:
> Would a patch for this be welcome? Does anyone have any suggestions or ideas? 
> I was thinking it should just respect current value of 
> `org-id-link-to-org-use-id` but maybe there should be something more specific?

Sounds useful to me. Ideally, it would be even better to remove
hard-coded replacements in org-capture-fill-template and use some kind
of (?char . #'fill-function) alist to allow more flexibility.

Best,
Ihor

Re: Empty headline titles unsupported: Bug?

[Ihor Radchenko]

Tom Gillespie  writes:

> Hi David,
> Laundry produces a full s-expression representation of the org
> parse tree (though it is still evolving). I haven't added a pass that
> converts it to some Racket internal representation (probably will be
> structs). If you get it installed and put #lang org at the top of an
> org file you can use racket-mode to parse arbitrary org files, though
> you may hit an error and will definitely encounter an
> incomplete/incorrect parse since it is still a work in progress. Best,
> Tom

Hi, I looked through your code. I saw some hand-written tests on
grammar. Would you be interested in converting those tests into tests in
test-org-element test suite? If the same tests are used for org-element
itself and for your parser, we can easily make sure that incorrect
parsing is avoided. Or you can even reuse the built-in tests for testing
your code (say, by remapping org-element-at-point calls in the tests
to analogous function from your parser).

Best,
Ihor

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Stefan Nobis]

Nicolas Goaziou  writes:

> By default, no export processor is selected. All citations are
> removed from output, and print_bibliography keywords, ignored.

As I'm coming from LaTeX and have been bitten more than once by
missing citations in the output (which is solved far better today by
biblatex), I would say this is not a very good default.

Citations should never be removed (or only with quite some effort). If
you publish a text where citations have been removed by accident,
that's asking for much trouble.

Therefore I would suggest to set some sensible default that at least
does not remove citations. For example a simple ASCII export with
number or author-year style could be the default citation export for
all back-ends. For quite some users (e.g. non-academic, internal
white-papers etc.) this may be also a "good enough" solution, so they
get easy citation support OOTB.

Everyone else would choose some more sophisticated back-end.

> It could be possible to change `org-cite-export-processor' so it
> becomes an alist where you can associate back-ends to processors.
> But I can't see how to transpose it nicely to cite_export keyword.

What about "cite_export" for a single/default export engine and
"cite_export_" (with "" something like "html",
"latex", "md", etc.) for overriding the citation exporter for the
given back-end, e.g.

cite_export ascii
cite_export_latex biblatex chicago
cite_export_html csl "some style"

(I forgot about the correct syntax for cite_export, so just a really
rough sketch to illustrate the idea).

Would that be feasible?

> I'm not convinced this would be an improvement either. For example,
> you may want to use two different processors with the same back-end.

I'm not sure if this is true for many back-ends. Currently, I would
assume that this is only the case for the LaTeX back-end (e.g.
preparing a paper for different journals with different citations
requirements). But in this case LaTeX has already quite some tools
that could be utilized. All the different kinds of citation commands
are there to be able to easily switch styles for the whole document
(within a single back-end).

I think what I'm trying to say is, that for the simple Org user it may
be easier to handle peculiarities of his back-ends (like HTML and
LaTeX) that it is for him to write custom Elisp to use exporter A for
HTML and exporter B for LaTeX.

-- 
Until the next mail...,
Stefan.

Re: [BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Richard Stanton]

On May 28, 2021, at 11:41 PM, Ihor Radchenko  wrote:
> 
> Richard Stanton  writes:
>> I currently load org using straight.el as follows:
>> ...
>> (use-package org-contrib
>>  :after org
>> ...
>> (use-package org
>>  :after (jupyter)
> 
> I suspect that something else is pulling built-in org version before
> jupyter gets loaded. To make sure that the straight version of Org mode
> is loaded, I recommend putting the following at the beginning of your
> init.el:
> 
> (straight-use-package '(org :type git :repo 
> "https://code.orgmode.org/bzg/org-mode.git";))
> (straight-use-package '(org-contrib :type git :repo 
> "https://git.sr.ht/~bzg/org-contrib";))
> 
> To debug similar issues, you might set use-package-verbose to t at the
> beginning of your init.el and examine the *Messages* buffer after
> startup.

Thanks for the suggestion, Ihor. I’ll experiment.