Re: [PATCH] ob-R output file with graphics parameter

[Timothy]

Jack Kamm  writes:

> I think it would still make sense though, and would be beneficial beyond
> ob-R. According to [1], the "graphics" and "link" arguments don't do
> anything unless used with "file", so it would make sense for them to
> automatically add the "file" argument.

Mmmm, I think it would be good if we could make it so it's generally
less effort to create plots.

Would it be strange if running the code block with just

:output graphics

Automatically added "link" if *only* graphics is set, and generated a
file name if no :file is set?

I think it would be nice if I could declare a "figures directory"
(default to "/tmp" or "."?) for exactly this.

--
Timothy

Re: [PATCH] ob-R output file with graphics parameter

[Jack Kamm]

Hi Jeremie,

>> The requirement for a second file parameter was added in Org 9.3 to
>> support the use case in this thread:
>>
>> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/
>>
>> But this syntax is annoyingly verbose for ob-R users, and also broke
>> lots of ob-R examples prior to Org 9.3.
>>
>> A simple fix might be to have the "graphics" flag implicitly add the
>> "file" flag as well. But we would need to first check that this doesn't
>> break other use cases.
>
> I do agree with this solution. If the current specification works, we
> could make it easy for ob-R user by implicitly adding a file flag. But
> as far as I understand, the change will have to be made in ob-core.el.

Hmm, I think you're right -- this would have to be done in ob-core.el.

I think it would still make sense though, and would be beneficial beyond
ob-R. According to [1], the "graphics" and "link" arguments don't do
anything unless used with "file", so it would make sense for them to
automatically add the "file" argument.

[1] https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation

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

[Bruce D'Arcus]

On Fri, Jul 2, 2021 at 5:21 PM Nicolas Goaziou  wrote:
>
> 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.

Is it possible to have three options?

1. if on "cite" prefix, edit style
2. if on citation-reference, edit reference
3. else (like where point is after a semi-colon but within the
citation), append reference

So the difference with current behavior is 1 would be more
constrained, and 3 would be a new option.

Bruce

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

[Bruce D'Arcus]

On Fri, Jul 2, 2021 at 6:33 PM Nicolas Goaziou  wrote:

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

You're right.

It is likely less work, with better results, for me to adapt what you
do with the basic insert function to my package, than vice-versa.

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

Confirmed.

Vertico has no such issue, with a very similar UI/UX to selectrum.

Bruce

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

[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] Exporting to pandoc md (and from there to zotero odt)

[Anders Johansson]

> Anders, I just want to say that I tested this out and it works great. It's 
> quite shocking, actually, to have such an easy path from org to odt with live 
> citations.  I'd love to see this stuff in MELPA or otherwise made more 
> generally accessible, as i think it fills a substantial need.

Hi Matt,
Great that it works for you! I have also been testing it out a bit
over the last few days (along with transferring from helm to the newer
completion packages, spurred by testing the nice completion given by
bibtex-actions. Thanks Bruce).

I do miss some of the possibilities of customizing the odt export
(easier when exporting via ox-odt). In particular having numbered
sections, which doesn't seem to be supported for odt exports from
pandoc (https://pandoc.org/MANUAL.html#option--number-sections). I
just added a custom variable for passing additional parameters to
pandoc in ox-md-pandoc-zotero (at
https://gitlab.com/andersjohansson/ox-md-pandoc-zotero), but
apparently, --number-sections didn't make a difference for odt.

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

[Bruce D'Arcus]

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

> "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.
>

Oh good.

Let me revise then.

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.

It's hard to remember keys if you have hundreds or thousands.

In bibtex-actions, I added some hidden data to the search string, including
the key, to ensure uniqueness.

> 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?
>

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

> 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.
>

Makes sense.

Bruce

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

[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

[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

[John Kitchin]

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).




John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Fri, Jul 2, 2021 at 4:59 PM Bruce D'Arcus  wrote:

>
>
> On Fri, Jul 2, 2021, 4:14 PM Nicolas Goaziou 
> wrote:
>
>> "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?
>
>
> Probably that would work.
>
> 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.
>
> If you do, ideally it would be extensible/configurable.
>
> Or is the latter already the case?
>
> OTOH, IDK how much you feel the need to get everything done before merger,
> or whether some pieces can wait?
>
> Bruce
>
>

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

[Bruce D'Arcus]

On Fri, Jul 2, 2021, 4:14 PM Nicolas Goaziou  wrote:

> "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?


Probably that would work.

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.

If you do, ideally it would be extensible/configurable.

Or is the latter already the case?

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

Bruce

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

[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

[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

Exporting to LaTeX versus Beamer: how to take different actions depending on export format?

[Richard Stanton]

I’ve been experimenting with using a single org file to generate an article 
when exported to LaTeX (or HTML) and a Beamer presentation when exported to 
Beamer, without requiring any edits to the org file itself. 

For this to be really useful, the exporter has to be able to do different 
things depending on which output format you’ve asked for. 

1) At a minimum, you need to be able to have text included in the article that 
is not included in the Beamer presentation and vice versa, so that you can 
have, say, a paragraph in the article vs. an itemized list in the Beamer 
presentation. This can be taken care of relatively easily using one of several 
conditional-compilation packages available for LaTeX. If people are interested, 
I’ve uploaded a simple example to 
https://faculty.haas.berkeley.edu/stanton/orgLatexBeamer/ 


2) However, some things are not so easy. For example, suppose I’m using the 
listings package to include some code in my document, e.g.,

#+begin_src python
  print(“Hello, world”)
#+end_src

This works fine as long as I’m OK with the default output format. But suppose 
this listing is too long for my slide so I want to make the text smaller than 
normal. I can do that quite easily for both article and presentation output by 
putting a line like

#+attr_latex: :options basicstyle=\tiny

immediately before the source block. But suppose I only want to do this in the 
Beamer output and not in the LaTeX article output? I’ve tried 

#+attr_beamer: :options basicstyle=\tiny

but this doesn’t seem to work. And even if it did, what if I wanted the change 
in font size to occur only when I’m exporting to LaTeX but not Beamer? How can 
I do conditional things like this at the org-file level based on whether I’m 
exporting to LaTeX or Beamer?

Thanks for any suggestions.

Richard Stanton

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

[Bruce D'Arcus]

Also:

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.
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.

On Fri, Jul 2, 2021 at 12:11 PM Nicolas Goaziou  wrote:
>
> 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: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

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]".


On Fri, Jul 2, 2021 at 12:11 PM Nicolas Goaziou  wrote:
>
> 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: how to add a range of columns

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Friday,  2 Jul 2021 at 16:07, Uwe Brauer wrote:
>> The problem is the target @<<$3..@>>$3
>> 
>> There seems no option to specify such a range.

> Sorry, I didn't explain myself properly.  You can specify which rows
> should be calculated automatically so that you can then use a simple
> column formula without it extending to the full column:

> #+begin_src org
>   ,#+Name: check
>   |   | User1 | User2 | Result |
>   |---+---+---+|
>   | # | 1 | 3 |  4 |
>   | # | 4 | 8 | 12 |
>   | # |10 | 3 | 13 |
>   |---+---+---+|
>   |   | 7 | 9 ||
>   ,#+TBLFM: $4=$2+$3
> #+end_src


> If you type "C-u C-c *" to re-calculate the table, the last entry in the
> 4th column is not updated even though the expression says that column 4
> is the sum of columns 2 and 3.

> Once you start using some of these advanced features, you can make your
> formulas easier to read, e.g.:

> #+begin_src org
>   ,#+Name: check2
>   | ! | User1 | User2 | Result |
>   |---+---+---+|
>   | # | 1 | 3 |  4 |
>   | # | 4 | 8 | 12 |
>   | # |10 | 3 | 13 |
>   |---+---+---+|
>   |   | 7 | 9 ||
>   ,#+TBLFM: $4=$User1+$User2
> #+end_src

Thanks, I thought of that 

#+begin_src elisp
#+Name: check3
  |   | User1 | User2 | Result |
  |---+---+---+|
  |   | 1 | 3 | 4  |
  |   | 4 | 8 | 12 |
  |   |10 | 3 | 13 |
  |---+---+---+|
  | / | 7 | 9 ||
#+TBLFM: $4=$2+$3
#+end_src
which is a bit the antipode of your approach.

It just occurred to me that this approach has its limitations, let's go
step further 

#+begin_src elisp
#+Name: check2
  | ! | User1 | User2 | Result | New | Actual |
  |---+---+---++-+|
  | # | 1 | 3 |  4 |   6 ||
  | # | 4 | 8 | 12 |   9 ||
  | # |10 | 3 | 13 |  10 ||
  |---+---+---++-+|
  |   | 7 | 9 || ||
#+TBLFM: $4=$User1+$User2
#+end_src


Now I want to add also result and new, but only the first two rows, the
only way to do it seems to be your original approach.


#+begin_src elisp

#+Name: check2
  | ! | User1 | User2 | Result | New | Actual |
  |---+---+---++-+|
  | # | 1 | 3 |  4 |   6 | 10 |
  | # | 4 | 8 | 12 |   9 | 21 |
  | # |10 | 3 | 13 |  10 ||
  |---+---+---++-+|
  |   | 7 | 9 || ||
#+TBLFM: $4=$User1+$User2::@<<$6..@>>>$6=$4+$5
#+end_src

Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

modify citation links in a derived HTML backend

[Matt Price]

Hi,

(cc:ing Jens L. in case this is relevant for his dev work on org-re-reveal).

I'm experimenting with the new citation syntax in slideshows generated with
org-re-reveal.  Mostly it works fine, but cite-links don't function
properly in the slideshow because in reveal, internal links only work when
they refer to a slide (which will generally be generated from a headline in
org-re-reveal export). Otherwise, the framework will reject the location
change.  At least, that's how I read the code here:
https://github.com/hakimel/reveal.js/blob/ade234576e8ddd683cf16d0d8bb0236f37cf1a99/js/controllers/location.js#L32.


Ideally, there would be some way to override this behaviour, but at present
I don't see how to do that from within Reveal.

I also know it is possible to just eliminate the links using
org-cite-csl-no-citelink-backends, but that is a significant loss of
function.

Instead, I would like to modify the links that surround the individual
citations. At present, the generated code will look something like this:

Zubaida, 2009

and I'd like to change it to something like this:

Zubaida, 2009

>From what I can tell so far, the current behaviour of oc-csl is dictated by
a lambda defined in the citeproc package, and set via defconst in an alist
`citeproc-fmt--html-alist` defined in citeproc-formatters.el.

My question: what's the best way to override the output of citation objects
for a specific derived backend? Can I use an export filter? should I
instead use, I don't know, cl-letf to temporarily override some internal
function belonging to citeproc-formatters and return a modified link?

thanks as always for the help!

Matt

bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824

[Eli Zaretskii]

> From: Maxim Nikulin 
> Date: Fri, 2 Jul 2021 23:24:23 +0700
> 
> On 02/07/2021 19:37, Eli Zaretskii wrote:
> >> From: Maxim Nikulin
> >> Date: Fri, 2 Jul 2021 19:21:55 +0700
> >> Cc: Lars Ingebrigtsen
> >>
> >>> And with other handlers, this could be an
> >>> incompatible behavior change if the handler behaves differently when
> >>> its standard handles are connected to a pipe rather than a terminal
> >>> device.
> >>
> >> Example of such handler, please.
> > 
> > Why do you need one?
> 
> Because of I can not imagine such case for mailcap handler in Emacs yet 
> and, accordingly to you, "this could be an incompatible behavior change".

You don't need to imagine it, you just need to trust me that I know
what I'm talking about: it would be an incompatible change.

Is it possible to detect that the handler is one of those that are
affected by this issue?  If so, let's do that; it cannot be worse than
what you suggested, or worse than the current situation.

bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824

[Maxim Nikulin]

On 02/07/2021 19:37, Eli Zaretskii wrote:

From: Maxim Nikulin
Date: Fri, 2 Jul 2021 19:21:55 +0700
Cc: Lars Ingebrigtsen


And with other handlers, this could be an
incompatible behavior change if the handler behaves differently when
its standard handles are connected to a pipe rather than a terminal
device.


Example of such handler, please.


Why do you need one?


Because of I can not imagine such case for mailcap handler in Emacs yet 
and, accordingly to you, "this could be an incompatible behavior change".

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

[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: [wip-cite-new] Exporting to pandoc md (and from there to zotero odt)

[Matt Price]

Anders, I just want to say that I tested this out and it works great. It's
quite shocking, actually, to have such an easy path from org to odt with
live citations.  I'd love to see this stuff in MELPA or otherwise made more
generally accessible, as i think it fills a substantial need.

On Tue, Jun 29, 2021 at 2:29 PM Matt Price  wrote:

> Anders, just to be clear:  with your new exporters I can, as of today,
> insert the new [cite:@citekey] links using a better-bibtex-generated
> bibliography file, export to odt via pandoc, and then manage my citations
> with zotero in the resultant odt?
>
> it so... cool.
>
> On Wed, Jun 23, 2021 at 4:04 PM Bruce D'Arcus  wrote:
>
>> Cool!
>>
>> We should also get pandoc to support updated org-cite syntax.
>>
>> https://github.com/jgm/pandoc/issues/7329
>>
>>
>> On Wed, Jun 23, 2021, 12:57 PM Anders Johansson 
>> wrote:
>>
>>> Hi all,
>>> I appreciate the work done on the cite functionality!
>>> I use zotero for managing my library and have previously used zotxt
>>> and org-zotxt (along with some additions in my zotxt-extra library)
>>> for being able to cite in org-mode and export correctly to various
>>> formats.
>>> https://gitlab.com/egh/zotxt
>>> https://gitlab.com/egh/zotxt-emacs
>>> https://gitlab.com/andersjohansson/emacs-zotxt-extra
>>>
>>> Zotxt has used a custom link format for citations (similar to org-ref)
>>> which links to zotero but optionally also contains a citekey (defined
>>> via the zotero-better-bibtex extension to zotero). I actually wrote my
>>> PhD thesis with this setup, but the connection to Zotero has always
>>> felt a little wobbly and Zotero is also quite slow for my large
>>> library.
>>>
>>> Now seems to be a great time to convert to a workflow with the new
>>> cite format. To enable a conversion from org mode to word processors
>>> with Zotero ”active” citations I created two libraries to manage this
>>> via pandoc and the pandoc filter created for the zotero-better-bibtex
>>> extension.
>>> (see: https://retorque.re/zotero-better-bibtex/exporting/pandoc/)
>>>
>>> This allows me a workflow like:
>>> 1. keep an updated  .bib-file of my library in zotero (with the help
>>> of zotero-better-bibtex)
>>> 2. cite in org-mode (for me with completion via helm-bibtex and
>>> https://github.com/bdarcus/bibtex-actions/pull/113)
>>> 3. Export to an odt-file with active zotero citations (with oc-pandoc
>>> and ox-md-pandoc-zotero)
>>>
>>> I attach them here in case anyone else finds some part of this workflow
>>> usable.
>>> https://gitlab.com/andersjohansson/org-cite-pandoc
>>> https://gitlab.com/andersjohansson/ox-md-pandoc-zotero
>>>
>>> I couldn’t find any previous definitions for exporting to the pandoc
>>> cite format so I quickly hacked up org-cite-pandoc. I suppose it could
>>> be be widely useful and included in org. Feel free to use it as
>>> suitable (I have FSF copyright assignment for emacs).
>>>
>>> Best,
>>> Anders Johansson
>>>
>>

Re: how to add a range of columns

[Eric S Fraga]

On Friday,  2 Jul 2021 at 16:07, Uwe Brauer wrote:
> The problem is the target @<<$3..@>>$3
>
> There seems no option to specify such a range.

Sorry, I didn't explain myself properly.  You can specify which rows
should be calculated automatically so that you can then use a simple
column formula without it extending to the full column:

#+begin_src org
  ,#+Name: check
  |   | User1 | User2 | Result |
  |---+---+---+|
  | # | 1 | 3 |  4 |
  | # | 4 | 8 | 12 |
  | # |10 | 3 | 13 |
  |---+---+---+|
  |   | 7 | 9 ||
  ,#+TBLFM: $4=$2+$3
#+end_src

If you type "C-u C-c *" to re-calculate the table, the last entry in the
4th column is not updated even though the expression says that column 4
is the sum of columns 2 and 3.

Once you start using some of these advanced features, you can make your
formulas easier to read, e.g.:

#+begin_src org
  ,#+Name: check2
  | ! | User1 | User2 | Result |
  |---+---+---+|
  | # | 1 | 3 |  4 |
  | # | 4 | 8 | 12 |
  | # |10 | 3 | 13 |
  |---+---+---+|
  |   | 7 | 9 ||
  ,#+TBLFM: $4=$User1+$User2
#+end_src

HTH,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bug: clock-in from org-agenda freezes thread when enforce + todo keywords [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]

[Ihor Radchenko]

Timothy  writes:

> Marking as a patch for Woof.

Was is not marked? My patch message should have X-Woof-Patch header.

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

Timothy  writes:

> Hi Ihor,
>
> This thread is looking promising! Just wondering if you might have time
> to respond to William's latest reply?

Sure. Just descended from work staff down to the Emacs area in my TODO
list ;)

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

William Xu  writes:

> I need to make below additional change, otherwise it works perfectly.

Incorporated in the attached final version of the patch. 

> Looking at the changes, I see you changed below `concat' call to
> `format'. Is this in the end some bug in the `concat' implementation?

It is complex. I am not sure if it is a bug or just some obscure
implementation detail. See Emacs bug#48740
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48740

Best,
Ihor

>From 3f3b2780e5dea3a04eee869a46bf4662103b8143 Mon Sep 17 00:00:00 2001
Message-Id: <3f3b2780e5dea3a04eee869a46bf4662103b8143.1625234837.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 22 Jun 2021 23:38:29 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda

* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width.  The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'.  The visibility settings of current buffer
are taken into account.

(org--string-from-props): Removed.  It was only used by old
`org-string-width' code.

(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.

(org-looking-at-fontified): New function.  Like `looking-at', but make
sure that the match is fontified.

* lisp/org.el (org-get-heading): Make sure that heading is fontified.

(org--get-local-tags, org-get-tags, org-scan-tags): Add optional
argument `fontified'.  When non-nil, the returned tags are fontified.

* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks, org-tags-view, org-agenda-list, org-todo-list,
org-agenda-highlight-todo): Make sure that fontification is the same
with original Org buffers.  All the buffer-substring and match-data
queries are changed to ensure that region of interest is fontified.
Also, preserve composition properties, used i.e. by
`prettify-symbols-mode'.  The composition is usually set to be removed
on text change, so we do the changes inside
`with-silent-modifications'.

(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.

(org-agenda-highlight-todo): Use `format' instead of `concat' to
update the headline in agenda.  `concat' may sometimes copy
composition property (see the C code) breaking the composed regions in
agenda view.  See Emacs bug#48740 for more details.

Preserve fontification and composition of headlines and tags in
agenda.  If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.

In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers.  The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
 lisp/org-agenda.el | 146 +++--
 lisp/org-macs.el   | 134 +
 lisp/org.el|  36 +++
 3 files changed, 181 insertions(+), 135 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..3dff2b926 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
 		  (put-text-property (point-at-bol) (point-at-eol)
  'tags
  (org-with-point-at mrk
-   (org-get-tags
+   (org-get-tags nil nil t
 	(setq org-agenda-represented-tags nil
 	  org-agenda-represented-categories nil)
 	(when org-agenda-top-headline-filter
@@ -,9 +,12 @@ (defun org-agenda-list ( arg start-day span with-hour)
 	(put-text-property s (1- (point)) 'org-today t))
 	  (setq rtnall
 		(org-agenda-add-time-grid-maybe rtnall ndays todayp))
-	  (when rtnall (insert ;; all entries
-			(org-agenda-finalize-entries rtnall 'agenda)
-			"\n"))
+  (with-silent-modifications
+;; Composition property in entries may be self-destructed
+;; on change.  Suppress the self-destruction.
+	(when rtnall (insert ;; all entries
+			  (org-agenda-finalize-entries rtnall 'agenda)
+			  "\n")))
 	  (put-text-property s (1- (point)) 'day d)
 	  (put-text-property s (1- (point)) 'org-day-cnt day-cnt)))
   (when (and org-agenda-clockreport-mode clocktable-start)
@@ -4778,10 +4781,11 @@ (defun org-search-view ( todo-only string edit-at)
   (and (eq org-agenda-show-inherited-tags t)
    (or (eq org-agenda-use-tag-inheritance t)
 	   (memq 'todo org-agenda-use-tag-inheritance
-			  

Re: how to add a range of columns

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Friday,  2 Jul 2021 at 12:04, Uwe Brauer wrote:
>> I will have a look thanks (I already thought about commenting out
>> unwanted rows, but that looked ugly).

> The nice thing about the advanced features is they give you full control
> and none of the extra notation is exported.

Ok, I checked https://orgmode.org/manual/Advanced-features.html

I cannot see at the moment how your solution 

#+TBLFM: @<<$3..@>>$3=$1+$2

Could be replaced with the syntax explained in this page.

The problem is the target @<<$3..@>>$3

There seems no option to specify such a range.


smime.p7s
Description: S/MIME cryptographic signature

bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824

[Eli Zaretskii]

> From: Maxim Nikulin 
> Date: Fri, 2 Jul 2021 19:21:55 +0700
> Cc: Lars Ingebrigtsen 
> 
> > And with other handlers, this could be an
> > incompatible behavior change if the handler behaves differently when
> > its standard handles are connected to a pipe rather than a terminal
> > device.
> 
> Example of such handler, please.

Why do you need one?

bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824

[Maxim Nikulin]

On 02/07/2021 01:38, Eli Zaretskii wrote:

From: Maxim Nikulin Date: Fri, 2 Jul 2021 00:01:59 +0700

--- a/lisp/net/mailcap.el
+++ b/lisp/net/mailcap.el
-(start-process-shell-command command nil command)))

...

+(make-process
+ :name "mailcap-view-file" :connection-type 'pipe :noquery t
+ :buffer nil ; "*Messages*" may be suitable for debugging
+ :sentinel (lambda (proc event)
+ (when (and (memq (process-status proc) '(exit signal))
+(/= (process-exit-status proc) 0))
+   (message
+"Command %s: %s."
+(mapconcat #'identity (process-command proc) " ")
+(substring event 0 -1
+ :command (list shell-file-name shell-command-switch command


First, you replace start-process-shell-command with make-process, and
I'm not sure I understand why.  If all you want is to use pipes, why
not simply bind process-connection-type around the call to
start-process-shell-command?



+;; An alternative is `process-connection-type' let-bound to nil for
+;; `start-process-shell-command' call (with no chance to report failure).

---


If main process of the handler fails then show a message with exit
reason.

---^^


And with other handlers, this could be an
incompatible behavior change if the handler behaves differently when
its standard handles are connected to a pipe rather than a terminal
device.


Example of such handler, please.

Re: how to add a range of columns

[Eric S Fraga]

On Friday,  2 Jul 2021 at 12:04, Uwe Brauer wrote:
> I will have a look thanks (I already thought about commenting out
> unwanted rows, but that looked ugly).

The nice thing about the advanced features is they give you full control
and none of the extra notation is exported.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: how to add a range of columns

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Friday,  2 Jul 2021 at 11:23, Uwe Brauer wrote:
>> No I only want to add the parts of column $1 and $2 that are between the
>> two hlines

> Okay; problem 1 is that org formulas are not really vector based: a
> range on the left hand side says that each element in the range will be
> assigned the outcome of the right hand side so the right hand side
> should not be a vector.

>> (I wanted to use hline @I and @II and not the explict row
>> numbers, since this is more convenient. But it does to work with
>> explicit row numbers 

> Yes, you cannot use @I etc. in the range definition for the target.

> I can think of 2 options.  First, you can use relative addressing, i.e.:

> #+TBLFM: @<<$3..@>>$3=$1+$2

> where @<< means the second row and @>> the second last row.

Thanks, that was helpful

> Alternatively, you can introduce a new column at the start and use the
> "Advanced Features" of the spreadsheet described in the info manual
> section

> (org) Advanced features

> which will allow you to specify which rows should be evaluated (see the
> * option).

I will have a look thanks (I already thought about commenting out
unwanted rows, but that looked ugly).


smime.p7s
Description: S/MIME cryptographic signature

Re: how to add a range of columns

[Eric S Fraga]

On Friday,  2 Jul 2021 at 11:23, Uwe Brauer wrote:
> No I only want to add the parts of column $1 and $2 that are between the
> two hlines

Okay; problem 1 is that org formulas are not really vector based: a
range on the left hand side says that each element in the range will be
assigned the outcome of the right hand side so the right hand side
should not be a vector.

> (I wanted to use hline @I and @II and not the explict row
> numbers, since this is more convenient. But it does to work with
> explicit row numbers 

Yes, you cannot use @I etc. in the range definition for the target.

I can think of 2 options.  First, you can use relative addressing, i.e.:

#+TBLFM: @<<$3..@>>$3=$1+$2

where @<< means the second row and @>> the second last row.

Alternatively, you can introduce a new column at the start and use the
"Advanced Features" of the spreadsheet described in the info manual
section

(org) Advanced features

which will allow you to specify which rows should be evaluated (see the
* option).

HTH,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: how to add a range of columns

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Friday,  2 Jul 2021 at 10:42, Uwe Brauer wrote:
>> I'd like to add a range values of two columns something like this 

> I am not sure what you are trying to achieve.  Would you please explain
> in more detail?  It kind of looks like you are trying to add columns 1
> and 2 to get column 3?  If so, you could simply have:

> #+TBLFM: $3=$1+$2

No I only want to add the parts of column $1 and $2 that are between the
two hlines (I wanted to use hline @I and @II and not the explict row
numbers, since this is more convenient. But it does to work with
explicit row numbers 

I added a column to indicate what I want to add and want not. Is this
better explained?

#+begin_src elisp

#+Name: check
| User1 | User2 | Result | don't add |
|---+---++---|
| 1 | 3 | [4]| add   |
| 4 | 8 | [4]| add   |
| 9 | 3 | [4]| add   |
|---+---++---|
| 7 | 9 | [4]| don't add |
#+TBLFM: @I$3..@II$3=@I$1..@2$1+@I$2..@II$2
#+end_src







smime.p7s
Description: S/MIME cryptographic signature

Re: how to add a range of columns

[Eric S Fraga]

On Friday,  2 Jul 2021 at 10:42, Uwe Brauer wrote:
> I'd like to add a range values of two columns something like this 

I am not sure what you are trying to achieve.  Would you please explain
in more detail?  It kind of looks like you are trying to add columns 1
and 2 to get column 3?  If so, you could simply have:

#+TBLFM: $3=$1+$2

so I may have misunderstood.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

how to add a range of columns

[Uwe Brauer]

Hi 

I'd like to add a range values of two columns something like this 

#+begin_src elisp

#+Name: check
| User1 | User2 | Result |
|---+---+|
| 1 | 3 | [4]|
| 4 | 8 | [4]|
| 9 | 3 | [4]|
|---+---+|
| 7 | 9 | [4]|
#+TBLFM: @I$3..@II$3=@I$1..@2$1+@I$2..@II$2
#+end_src


But it does not work, so I am a bit puzzled. Any advice would be
welcome.

Uwe Brauer 

Re: how to use complex excel formula in org

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Thursday,  1 Jul 2021 at 18:28, Uwe Brauer wrote:
>> I currently have to collaborate with an excel file that contains quite a
>> bit of complex formula. 

> Do you need bi-directional collaboration?  If you do, I doubt there's a
> solution out there.  Collaboration with people using MS based tools is
> challenging (being polite here).

Xlsx-->org would be enough for the moment.

>> I cannot simply import the file via xlsx-->csv-->org

> xlsx is XML based so you could, in principle, read the information
> directly from the xl/worksheets/sheetN.xml component in the file (the
> xlsx file itself should be a zip archive).  The format will consist of
> entries such as

> FFXX...

> where FF would be the formula (and XX the value of that formula) for
> entry in A1.  Lots of detail omitted in the above, mind you.

Right, this is basically what I am trying to do now. A manual approach
of sorts.

I just realized that there are operations I am not sure how to do them
in org. I'll send a different post about it.


smime.p7s
Description: S/MIME cryptographic signature

Re: how to use complex excel formula in org

[Eric S Fraga]

On Thursday,  1 Jul 2021 at 18:28, Uwe Brauer wrote:
> I currently have to collaborate with an excel file that contains quite a
> bit of complex formula. 

Do you need bi-directional collaboration?  If you do, I doubt there's a
solution out there.  Collaboration with people using MS based tools is
challenging (being polite here).

> I cannot simply import the file via xlsx-->csv-->org

xlsx is XML based so you could, in principle, read the information
directly from the xl/worksheets/sheetN.xml component in the file (the
xlsx file itself should be a zip archive).  The format will consist of
entries such as

FFXX...

where FF would be the formula (and XX the value of that formula) for
entry in A1.  Lots of detail omitted in the above, mind you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

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

[Eric S Fraga]

On Thursday,  1 Jul 2021 at 23:16, Nicolas Goaziou wrote:
> Applied. Thanks to both of you.

Thank you!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-570-g7666d6
: Latest paper written in org: https://arxiv.org/abs/2106.05096