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

[Bruce D'Arcus]

On Wed, Jul 7, 2021 at 11:48 PM Timothy  wrote:

> wip-cite-new deals with citing from bibliographies, but I don't think it
> deals with within-document referencing --- should it?

It doesn't now.

I guess to break down the second question further:

1. Should it?
2. Can it? Could the design be extended to include internal referencing?
2. If yes to both, should that hold back merger now?

I've not thought about this a lot, but my tentative view ...

1. Maybe.
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].
3. No.

I say no in part because while it's possible it's fairly
straightforward to add this, it will take some thought, and there's
probably details to sort out.

And the code is ready, I think, based on the requirements that have
been the focus the past year+.

OTOH, perhaps this basic requirements question was raised before I
joined the discussion, and it was already rejected?

Either way, I don't think this should hold back merger now. It can be
added later if it makes sense.

Bruce

Re: [R example for org-table with ifs]

[Uwe Brauer]

>>> "GM" == Greg Minshall  writes:

Greg


> Uwe,
> well, *i* no longer remember how to read calc-like expressions.  and,
> i'm a notoriously poor R coders.  assuredly the following is not doing
> what you want, but possibly you'll get the idea.  (if 102.01 is, indeed,
> the correct answer, feel free to buy me a hot fudge sundae some day. :)


Thanks but I have to disappoint you the correct result should be 10.1

> cheers, Greg

> #+name: thing
> | / | <>  |<> | <> |  <> |   <> | <> | <>  |

> |   | | DMI G | DMNI H | ExNDM I | ExNDNM J | Result | Weight2 |
> |   | Weight: | 1 |0.2 |   1 |  0.1 || 0.1 |
> |---+-+---++-+--++-|
> |   | User1   | 0 |  0 |  11 |0 | 10.1   | |
> |---+-+---++-+--++-|

> #+TBLFM: $7=if($3>10,($3-10)*@3$8,0)+ min(10,$3)*@3$3+ min(10,$4)*@3$4 + 
> if($5>10,($5-10)*@3$8,0)+min(10,$5)*@3$5 +@3$6*$6;f1::

> - does "@3$3" mean the third column in the third row? 
yes
>   - is that the "DMNI H" column? That is 0.2
>   - is that the "User1" row? 

No, it is the weight row

> i replace "@3" with the last row of the input table.

> #+begin_src R :var some=thing :session R :colnames yes
>   ## in imported colnames, spaces are replaced with periods
>   some[,"Result"] <- ifelse(some[,"DMNI.H"] > 10, (some[, "DMNI.H"] - 10.0) *
>  (some[nrow(some), 
> "Weight2"]),
> 0.0) +
> (min(10, some[, "DMNI.H"]) * some[nrow(some), "ExNDM.I"]) +
> (ifelse(some[, "ExNDNM.J"] > 10, some[, "ExNDNM.J"] - 10 * 
> some[nrow(some), "DMNI.H"], 0)) +
> (min(10, some[, "ExNDNM.J"]) * some[nrow(some), "ExNDNM.J"]) +
> (some[nrow(some), "Result"] * some[, "Result"])
> #+end_src

Thanks I will play around a bit, but for the moment I think I have to
stick with calc

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: [R example for org-table with ifs] (was: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx))

[Greg Minshall]

Uwe,

well, *i* no longer remember how to read calc-like expressions.  and,
i'm a notoriously poor R coders.  assuredly the following is not doing
what you want, but possibly you'll get the idea.  (if 102.01 is, indeed,
the correct answer, feel free to buy me a hot fudge sundae some day. :)

cheers, Greg

#+name: thing
| / | <>  |<> | <> |  <> |   <> | <> | <>  |
|   | | DMI G | DMNI H | ExNDM I | ExNDNM J | Result | Weight2 |
|   | Weight: | 1 |0.2 |   1 |  0.1 || 0.1 |
|---+-+---++-+--++-|
|   | User1   | 0 |  0 |  11 |0 | 10.1   | |
|---+-+---++-+--++-|
#+TBLFM: $7=if($3>10,($3-10)*@3$8,0)+ min(10,$3)*@3$3+ min(10,$4)*@3$4 + 
if($5>10,($5-10)*@3$8,0)+min(10,$5)*@3$5 +@3$6*$6;f1::

- does "@3$3" mean the third column in the third row?
  - is that the "DMNI H" column?
  - is that the "User1" row?

i replace "@3" with the last row of the input table.

#+begin_src R :var some=thing :session R :colnames yes
  ## in imported colnames, spaces are replaced with periods
  some[,"Result"] <- ifelse(some[,"DMNI.H"] > 10, (some[, "DMNI.H"] - 10.0) *
 (some[nrow(some), "Weight2"]),
0.0) +
(min(10, some[, "DMNI.H"]) * some[nrow(some), "ExNDM.I"]) +
(ifelse(some[, "ExNDNM.J"] > 10, some[, "ExNDNM.J"] - 10 * some[nrow(some), 
"DMNI.H"], 0)) +
(min(10, some[, "ExNDNM.J"]) * some[nrow(some), "ExNDNM.J"]) +
(some[nrow(some), "Result"] * some[, "Result"])
#+end_src

#+RESULTS:
|  x |
||
||
| 102.01 |

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/)]

[Mark Barton]

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.

I don’t see outline as a minor mode listed when I use C-h m while in an org 
file expecting org-cycle.

Mark
> On Jul 7, 2021, at 6:35 AM, Nicolas Goaziou  wrote:
> 
> 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)
> 
> 
> Regards,
> -- 
> Nicolas Goaziou
> 

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

[Timothy]

Nicolas Goaziou  writes:

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

This may be much too late to raise this (sorry), but I've got a query.

At the moment org-ref allows for:
+ citing from a bibliography
+ referencing elements within the document

wip-cite-new deals with citing from bibliographies, but I don't think it
deals with within-document referencing --- should it?

In case it helps, here's a small example of referencing elements with
org-ref:

#+begin_src org
,#+caption: Wow, look a me. label:some-f
[[file:some-file.png]]

Have you seen cref:some-f ?
#+end_src

Exported LaTeX:

#+begin_src LaTeX
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{some-file.png}
\caption{Wow, look a me. \label{some-f}}
\end{figure}

Have you seen \cref{some-f} ?
#+end_src

I know that we can get a label added with #+name, but I don't know that
there's an easy way to reference it without org-ref. I feel like ideally
this should be something Org provides.

-- 
Timothy

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

[Matt Price]

I cannot believe this is finally happening, and I am so stoked and excited
about it. I've been using ~wip-cite-new~ in my classes this week, and these
new tools are absolutely transformative.

Thank you so much for the immense amount of work you put into this.  And
also to Bruce for championing it, and Andras and Denis and others for their
contributions. Really, I feel like there should be a parade.

Matt

On Wed, Jul 7, 2021 at 10:23 PM Thomas S. Dye  wrote:

> Aloha Nicolas,
>
> Good news! I'm looking forward to using this facility.
>
> Thanks to all the contributors.
>
> All the best,
> Tom
>
> Nicolas Goaziou  writes:
>
> > 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,
>
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>
>

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

[Thomas S. Dye]

Aloha Nicolas,

Good news! I'm looking forward to using this facility.

Thanks to all the contributors.

All the best,
Tom

Nicolas Goaziou  writes:


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,



--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [PATCH] Allow tangling to a list of files

[Tom Gillespie]

Reading over this with the new information about the use case, it
seems that using noweb to manage the many-to-many nature of a mapping
between blocks and files is a much better way to achieve the desired
result. In addition it is already supported and does not add more
complexity to an already complex part of org.

The one area that a noweb approach does not support is dynamic
construction of files at runtime on the basis of some information that
is only available at runtime, however that does not seem to be
important for this use case.

Therefore I suggest that the tangling behavior be left 1:1 block:file,
and if there is some desire to tangle to multiple files then noweb
should be used with multiple blocks. Obviously there is some
performance penalty here. Also this doesn't help with cases where we
want to tangle to hundreds of servers using tramp, but if that is the
use case then I would suggest that that operation not be hidden behind
:tangle. Instead tangle once and then use another elisp block write
all the files to their final destinations using tramp, ssh, or some
other means.

I personally have use cases for things like this, but even so I don't
think we wan't the :tangle parameter to be the way to do it. I would
suggest instead that if we want to enable a tangled file to be
automatically distributed to a number of different locations that we
provide a separate header argument so that the functionality is not
conflated with the tangle functionality. I don't have a good name for
it, but the objective seems to be something like :tangle-copy-to that
accepts a function returning zero or more paths, or a list of multiple
paths (I don't recall how/whether any of the babel args deal with
accepting multiple values).

Best,
Tom

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

[Bruce D'Arcus]

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.

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?

Bruce

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Tim Cross]

Marco Wahl  writes:

> Hi,
>
> org-attach-sync can be used to "Synchronize the current outline node
> with its attachments."  Which is great AFAICT.
>
> What do you think about letting org-attach-sync remove the attachment
> directory if it's empty?
>
> Rationale: Nobody needs an empty attachment directory.
>   

This seems pretty reasonable to me provided it only removes an
attachments directly which was created by org-attach-sync. If the
directory existed or was created by something external, then removing it
probably should not be done.

Likely this is something which should be controllable via a custom
setting?


-- 
Tim Cross

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

[William Denton]

On 8 July 2021, Nicolas Goaziou wrote:


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


I do not object---I am eager to try it!  I haven't experimented with the work as 
it was being done, but I was very impressed with and grateful for all the work 
that everyone did on this.  I'm a librarian, so I know how ridiculous and 
bizarre citation formats are, but I still learned a lot about how complex it is 
to write code to handle them.


My thanks to everyone involved for doing such great work to add a wonderful new 
feature to Org.


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.

[wip-cite-new] Merging tomorrow?

[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: [PATCH] Allow tangling to a list of files

[Jacopo De Simoi]

‐‐‐ Original Message ‐‐‐

On Wednesday, July 7th, 2021 at 7:28 PM, Tim Cross  
wrote:

> Jacopo De Simoi jacop...@protonmail.com writes:
>
> > In fact the files are different, since each source block is tangled to a
> >
> > possibly different subset of files.
> >
> > The logic for which files to tangle according to which parameter or tags 
> > can be
> >
> > implemented by some lisp magic such as
> >
> > #+begin_src sh :tangle (filenames-according-to-situation)
> >
> > #+end_src
> >
> > So my patch provides the framework to do this, but the implementation is 
> > left
> >
> > to the author.
>
> This possibly makes your intention a little clearer.
>
> It seems to me that what you are asking for is not support for
>
> specifying a list of files, but support for specifying a function which
>
> will return the filename of the file to use for the tangled output? That
>
> is something I could see as being more useful than the ability to set a
>
> list of output filename. Things could be defined so that if the function
>
> returns nil, the block is not tangled, if it returns 't the block is
>
> tangled to the default output file and if the function returns a string,
>
> that string is interpreted as a filename which is to be used as the
>
> output target for the tangle.

This is (mostly) already in place, lisp is indeed evaluated as an argument of 
the : tangle argument (although the docs do not mention this fact).

 What my patch is providing is support for the case in which the function 
returns a list of filenames rather than just one filename (or yes or no)

The "(mostly)" above refer to the fact that 't is not processed correctly (but 
that would be an easy fix)

nil used to work before being broken by a recent commit.  I posted a patch on 
July 1 to address this issue, but it has not been considered yet.

>
> I think I might have seen another request for this type of functionality
>
> on the list recently? Such functionality seems like a useful addition.
>
>
> 
>
> Tim Cross

Re: [new patch] [PATCH] make org-notify support for macOS desktop notification

[stardiviner]

Hi Chris, thanks for your work. I have a question, will your patch of 
notification code be merged to upstream?
If yes, I think my patch will be not necessary. If no, then I think add a my 
workaround for macOS is considerable.

> On Jul 7, 2021, at 2:23 AM, Christian Hopps  wrote:
> 
> It supports imagemagick (specify —with-imagemagick), and it includes svg by 
> default, I simply forked the railwaycat version and added the native 
> notification code.
> 
> Thanks,
> Chris.
> 
>> On Jul 6, 2021, at 11:30 AM, stardiviner > > wrote:
>> 
>> Thanks for your suggestion. Does your Emacs build supports imagemagick image 
>> view and svg feature support? Because company-mode now have built-in icons 
>> support. This is the reason that I switch from https://emacsformacosx.com/ 
>>  to Homebrew cask Emacs version.
>> 
>>> On Jul 6, 2021, at 12:21 PM, Christian Hopps >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Please consider: I added full native notification support to the popular OS 
>>> X Emacs build available in homebrew. This supports rewrites 
>>> notifications-notify defun to use the native code rather than dbus, and so 
>>> everything "Just Works".
>>> 
>>> Info can be found here:
>>> 
>>> https://github.com/choppsv1/homebrew-emacsmacport 
>>> 
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>> stardiviner mailto:numbch...@gmail.com>> writes:
>>> 
 Here is the new patch which invokes notifications though Emacs built-in 
 API `ns-do-applescript`.
 
 [2. text/x-patch; 
 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch]...
 
 
 
> On Jul 6, 2021, at 8:06 AM, Tim Cross  > wrote:
> 
> 
> stardiviner mailto:numbch...@gmail.com>> writes:
> 
>>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin >> > wrote:
>>> 
>>> On 05/07/2021 10:50, stardiviner wrote:
 I updated the patch, I found the package `osx-lib` contains solution.
 So I removed the directly osascript process invocation.
>>> 
>>> I have no objections any more. On the other hand I have no access to 
>>> macOS, so
>>> I have not tested this patch. Feel free to ignore comments from this 
>>> message,
>>> they are mostly matter of taste.
>>> 
>>> I expect that a simple script "notify-send" may allow to avoid 
>>> modification of
>>> code. Something like (untested, unsure concerning "quoted form of ...")
>>> 
>>> #!/usr/bin/env osascript
>>> display notification (item 1 of argv)
>>> 
>>> However if osx-lib in is installed automatically, it may be more 
>>> convenient.
>>> Unsure if some of currently supported linux distributions have 
>>> notify-send
>>> that can not handle title as the first argument.
>>> 
 -  ((fboundp 'notifications-notify)
 +  ((and (eq system-type 'gnu/linux) (fboundp 
 'notifications-notify))
>>> 
>>> Does it mean that `notifications-notify' is bound but it does not work 
>>> on
>>> macOS? If so, maybe it is better to put new clause for 'darwin above 
>>> and to
>>> drop 'gnu/linux here. From my point of view, it is preferable to avoid
>>> additional requirement for `notifications-notify'. If someone will 
>>> create a
>>> feature request for `notifications-notify' for macOS, it will just work
>>> without installing of additional packages as soon as such feature is
>>> implemented.
>>> 
>>> 
>> I indeed tried `notifications-notify`. And it does not work, reports 
>> error that
>> it needs dbus. PS. I used the Homebrew formulae version Emacs.
>> I considered the order of conditions. Because notifications and 
>> notify-send etc
>> requires dbus. So I guess only Linux supports that. So add system-type 
>> detection
>> will be better. WDYT?
> 
> I think you can add dbus support to macOS using homebrew and that might
> resolve the issue. At the very least, this will need to be investigated
> because otherwise, adding this patch may break configurations for users
> who have added dbus support via homebrew and have notifications working,
> but have not installed the osx-lib package.
> 
> My only small concern with your proposed changes is that it will add a
> dependency on a new package osx-lib, which I think is only available in
> melpa. At the very least, this will need to be documented somewhere.
> However, I'm not sure what the situation is wrt adding code which
> depends on an external package which is not available in either elpa or
> nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code
> which 'encourages' the use of melpa packages will not be acceptable.
> 
> --
> Tim Cross
> 
>>> 
>> 
> 

Re: [PATCH] Allow tangling to a list of files

[Tim Cross]

Jacopo De Simoi  writes:

>
> In fact the files are different, since each source block is tangled to a 
> possibly different subset of files. 
>
> The logic for which files to tangle according to which parameter or tags can 
> be 
> implemented by some lisp magic such as 
>
> #+begin_src sh :tangle (filenames-according-to-situation)
> #+end_src
>
> So my patch provides the framework to do this, but the implementation is left 
> to the author.
>

This possibly makes your intention a little clearer.

It seems to me that what you are asking for is not support for
specifying a list of files, but support for specifying a function which
will return the filename of the file to use for the tangled output? That
is something I could see as being more useful than the ability to set a
list of output filename. Things could be defined so that if the function
returns nil, the block is not tangled, if it returns 't the block is
tangled to the default output file and if the function returns a string,
that string is interpreted as a filename which is to be used as the
output target for the tangle.

I think I might have seen another request for this type of functionality
on the list recently? Such functionality seems like a useful addition. 


-- 
Tim Cross

Re: [PATCH] Allow tangling to a list of files

[General discussions about Org-mode.]

Dear Tim, 

On Tuesday, July 6, 2021 3:30:40 AM EDT Tim Cross wrote:
> Jacopo De Simoi via "General discussions about Org-mode."  writes:
> > Hi Greg,
> > 
> > thanks for your comments!
> > 
> > On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote:
> >> hi, Jacopo,
> >> 
> >> i'm not convinced this is needed over and above your old "solution" of
> >> using <> witn N-different source blocks, each :tangle'ing to a
> >> different file.
> > 
> > To be honest I never quite managed to get it work... =)
> > 
> > My point here is to be able to have one org file tangle'ing to several,
> > slightly different outputs.  Ideally I want to use one readable literate
> > config for all my machines; the config can then be published (or
> > exported) to html
> > 
> > Say I want to create an org file to tangle .tmux.conf (or .zshrc) for
> > different machines; then most of the conf file would be the same (and
> > each such block would be tangled to all files) whereas some specifics
> > could be tangled to corresponding files only (e.g. ALIASes or EDITORs)
> > 
> > Even if a solution using noweb could work, I find being able to tangle to
> > a
> > list of files more readable and elegant. Especially when exporting the org
> > in an external format, I think the noweb solution would look like a hack,
> > whereas a solution with tangle-to-list would be much easier to parse.
> > 
> >> but, i'm curious -- in the example you sent, did you miss a ":tangle" on
> >> the "#+begin_src" line?
> > 
> > Yikes! of course I did! Good catch.
> > 
> >> > #+begin_src sh '("filename1" "filename2")
> >> > #my script
> >> > #+end_src
> 
> I'm not sure I fully understand the rationale behind this patch. It
> seems to be very niche oriented and not a terribly useful general
> feature. It feels like it is just a partial solution to a problem (i.e.
> generate multiple different files from the same org file). If this is
> the case, then you probably need some additional control structures to
> determine which bits/blocks go into which files. From what I can see,
> all the patch is doing is creating multiple files, which I imagine would
> then need to be modified anyway?
> 
> If I understand it correctly, all the files will end up with the same
> content. This seems odd to me. Am I missing something (like some ability
> to have different contents tangled to different files)?
> 
> If it is just generating multiple copies of the same file, I don't
> really see the value. It would be less processing/overhead to just
> create one file and then copy it (possibly copying it to different
> locations, such as a tramp filespec). Using the 'devops' style of org
> files, this could even be coded into a script block which could be
> executed after tangling.

In fact the files are different, since each source block is tangled to a 
possibly different subset of files. 

The logic for which files to tangle according to which parameter or tags can be 
implemented by some lisp magic such as 

#+begin_src sh :tangle (filenames-according-to-situation)
#+end_src

So my patch provides the framework to do this, but the implementation is left 
to the author.

I agree that if you tangle to shell or to any programming language, you can 
set up the checks for each usecase in the programming language itself.  

I developed this solution for plaintext config files (e.g. xkb maps, or KDE 
shortcut config files)  which are static and parsed as a single chunk.

I admit that the use case is quite specific, but it seemed to me a quite 
natural generalization of the current behavior, and worth adding.

Thanks for the discussion! It's really helpful to put things in perspective. 


> 
> Personally, I've used a different approach to a similar problem. For
> example, my .zshrc and init.el files have conditional tests which check
> either the hostname or platform type and set things accordingly. This
> way, I only ever have one .zshrc and one init.el file for all systems,
> but they behave differently based on the system they are running on.
> When the config does not support conditional tests, then I'll have
> different source blocks included in the tangle. Currently, I just turn
> off blocks I don't want (:tangle no), but I guess I could do something
> more sophisticated using noweb or tags, but the manual setting has
> worked fine so far as I don't have many files requiring this.
> 
> --
> Tim Cross



signature.asc
Description: This is a digitally signed message part.

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

[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: convert subtree or nested list to table

[Matt Price]

It's totally interesting. It's not quite designed for what I'm looking to
do and is perhaps a bit overpowered for my limited needs but I'm going to
test whe nI have a little mroe time!

On Tue, Jul 6, 2021 at 7:51 AM Uwe Brauer  wrote:

> >>> "MP" == Matt Price  writes:
>
> > I have to write a number of text-heavy documents which need to be
> delivered
> > as tables with wrapped paragraphs in most cells. Working directly in
> table
> > format is pretty arduous and uncomfortable.  Has anyone ever written a
> > function to accept a list or subtree as input and process it into a
> table?
>
> > If anyone has done something similar, I'd love some tips!
>
> There is org-listcruncher, which I started to use some days ago. For my
> needs it works quite nicely.
>

Re: convert subtree or nested list to table

[Matt Price]

thank you Juan Mnauel. I'm testing it out, but I do wonder if I would
really rather work with lists and some CSS!

On Tue, Jul 6, 2021 at 8:56 AM Juan Manuel Macías 
wrote:

> Hi Matt, sorry for the slow reply...
>
> Matt Price writes:
>
> > I'd love to try that, thanks. I think it would be really helpful.
> > Much appreciated!
>
> Some previous caveats:
>
> - *The code is very raw*. I wrote it almost as a "proof of concept" for
>   my personal use, therefore it is quite improvable. In any case, it
>   works (but i don't know if it will help you get what you want...).
>
> - The attached example is optimized to export to LaTeX. Use the tabularx
>   environment, which is ideal for tables with a lot of textual content.
>
> - As for the code, there are two basic functions:
>   `my-org/edit-table-cell' and
>   `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
>   you have to write something in that cell first.
>
> - The basic idea is that within each cell, the content is a single line
>   (unfilled). In the edit buffer, the content is filled. There are two
>   macros to indicate a line break and a paragraph end: {{{nl}}} and
>   {{{par}}}. In the edit buffer you can put line breaks and white lines,
>   but all of that is lost inside the cell once saved (all is a single
>   line), so those macros are needed to indicate line or paragraph breaks
>   (in LaTeX).
>
> Best regards,
>
> Juan Manuel
>
>

Re: convert subtree or nested list to table

[Matt Price]

I think this is exactly what I want (with just a little moreprocessing).
Thank you so much for the idea!

I'm having a little bit of trouble getting the same output as you though,
and I'm wondering if there might be a setting that I need to change.

Here is what I tried, and the result. Do you have an idea of what is going
wrong here?

Thank you!



#+NAME:essay-rubric
- Category
  - A
  - B
  - C
  - D
  - F
- Writing
  - great
  - good
  - ok
  - lousy
  - awful

#+begin_src emacs-lisp :var contents=essay-rubric :results table
contents
#+end_src

#+RESULTS:
#+begin_src emacs-lisp
| (("Category" |
#+end_src
-
On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin  wrote:

> Hi Matt
>
> Le 05/07/2021 à 21:44, Matt Price a écrit :
> > I have to write a number of text-heavy documents which need to be
> > delivered as tables with wrapped paragraphs in most cells. Working
> > directly in table format is pretty arduous and uncomfortable.  Has
> > anyone ever written a function to accept a list or subtree as input
> > and process it into a table?
> >
> > If anyone has done something similar, I'd love some tips!
>
> Maybe you could use builtin Babel
> Hereafter you have a starting point
> - Give a name to your input Org list
> - Process it with Emacs-Lisp (or whatever language you are comfortable
> with) to output it as a table
>
>
>  self contained Org Mode example _
>
> Example of a named list
> #+NAME: BBB
> - abc
>   + 123
>   + 456
> - def
>   + red
>   + blue
> - ghi
>   + big
>   + small
>
> Example of converting the named list into a table with Emacs-Lisp
> #+begin_src elisp :var bbb=BBB :results table
> bbb
> #+end_src
>
> #+RESULTS:
> | abc | (unordered (123) (456))   |
> | def | (unordered (red) (blue))  |
> | ghi | (unordered (big) (small)) |
> ___
>
>
>

[WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

Hi,

org-attach-sync can be used to "Synchronize the current outline node
with its attachments."  Which is great AFAICT.

What do you think about letting org-attach-sync remove the attachment
directory if it's empty?

Rationale: Nobody needs an empty attachment directory.
  

Ciao,
-- 
Marco

Re: LaTeX-producing code : how to export results to HTML/ODT

[John Kitchin]

I am not sure you have the best math example, isn't the syntax \[\] for
unnumbered equations in latex? What would it even ref? In the export, you
can see that there is no label in the tex at least.

#+BEGIN_SRC emacs-lisp :exports both :results value drawer :post
caption(name="eq-integral", caption="This is an equation.", data=*this*)
  "\\begin{equation}
\\int_0^2 e^x dx
\\end{equation}"
#+END_SRC

works better for latex. I guess that is always going to be some kind of
limitation.

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 Wed, Jul 7, 2021 at 9:58 AM CHARPENTIER Emmanuel <
emmanuel.charpent...@aphp.fr> wrote:

> > Here is a way way to combine the output with a name/caption.
>
>
> Slight modification : caption in emacs-lisp (to avoid sh blocks) : see the
> enclosed archive (necessary to avoid anti-spam blocking by my ISP).
>
> Mixed results (see enclosed archive):
>
> - ODT exports : I get a captioned block containing the equation, correctly
> referenced.
>
> - HTML : I get the equation (via MathML/Mathjax), no caption and a
> reference to nothing visible.
>
> - PDF via LaTeX : I get the math and an undefined reference (??).
>
> - Docx from ODT : mangled math, unrelated caption, reference to nothing.
>
> There is a nice idea, but it is still perfectible. I'm afraid that
> filering by exporter is still necessary...
>
> Thank you again !
>
> --
> Emmanuel Charpentier
>
>

Re: org-table: deleting columns not always actualise the formulas.

[Uwe Brauer]

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

> On Wednesday,  7 Jul 2021 at 18:22, Uwe Brauer wrote:
>> Off the record: good look tonight. Although

> Yesterday's match was fantastic even though the outcome was not what I hoped 
> for.

I agree, I think it is fair to say, that Spain was the better team, but
then football is about scoring not about playing aesthetically pleasing. 

When Italy started the penalty shootout, I thought this is a lost case,
since, I think, most teams that started the penalties, won.

As for tonight: I am torn between England (because it took them so long
to reach a semi finals and even being the favorite) and Denmark (because what
happened to Christian Eriksen.

A last word concerning the Germany England game. 

England deserved the victory, although if Müller had kept his nerve and
made that goal things might have turned out differently.

So as I said good luck tonight: might the better team win.


smime.p7s
Description: S/MIME cryptographic signature

Re: convert subtree or nested list to table

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> Hi Uwe, thanks for testing the code.
> Uwe Brauer writes:

>> I am running (a couple of week old) GNU emacs master and org-mode git
>> master. I even restarted my emacs session
>> 
>> What do I miss?

> I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
> case everything works as expected (taking into account that with this
> code of mine the expectations have to be modest :-).

Could also be some of my pkg file. I might check it 
starting emacs -q


smime.p7s
Description: S/MIME cryptographic signature

Order schedule for meds using Org table

[tomas]

On Wed, Jul 07, 2021 at 01:00:48PM -0400, Jude DaShiell wrote:
> I am planning a table to show re-order dates for 4 otc meds I take.  They
> haven't got the same pill counts and another constraint will be not to
> order on weekends.  Since this is intended to show repeating re-order
> dates I figure to use formulas with pill counts in particular cells as
> repeater items for the dates and have the dates show up vertically down
> each four columns.  It will be interesting to see if this works and if it
> does, I'll share it with the list since maybe others would be able to use
> something like this in future.

Hey Jude,

I'm not very experienced with org table, but re-formulated your
subject. It nearly fell prey to my (wetware) spam detector, so
perhaps it had a worse fate with more strict ones...

Cheers
 - t


signature.asc
Description: Digital signature

Re: convert subtree or nested list to table

[Juan Manuel Macías]

Hi Uwe, thanks for testing the code.

Uwe Brauer writes:

> I am running (a couple of week old) GNU emacs master and org-mode git
> master. I even restarted my emacs session
>
> What do I miss?

I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
case everything works as expected (taking into account that with this
code of mine the expectations have to be modest :-).

I will do a test on Emacs master...

Best regards,

Juan Manuel

Re: Bug: Unexpected behavior marking recurring tasks as DONE

[Alan Ristow]

I think I have solved this, though I am not really sure why the solution 
works. As noted previously, my org-todo-keywords are defined as follows:


  (setq org-todo-keywords
    '((sequence "TODO(t)" "NEXT(n)" "STARTED(s)" "WAITING(w@/!)" 
"|" "DONE(x!)" "DELEGATED(d@)")

  (sequence "DEFERRED(f@/!)" "INACTIVE(i@/!)" "|" "CANCELED(c@)")))

By trial-and-error with a minimal init.el file, I discovered that 
removing the exclamation point from the DONE fast access key solved the 
problem, at least in the testing I have done so far (with both the 
minimal init.el and my full configuration). That is to say, the new 
setting is as follows:


  (setq org-todo-keywords
    '((sequence "TODO(t)" "NEXT(n)" "STARTED(s)" "WAITING(w@/!)" 
"|" "DONE(x)" "DELEGATED(d@)")

  (sequence "DEFERRED(f@/!)" "INACTIVE(i@/!)" "|" "CANCELED(c@)")))

I have not touched this variable in many years, and as far as I can tell 
the documentation on the use of "!" is the same as it has been since the 
day I started using org. Even without the "!", the time I completed the 
task still gets logged in the LOGBOOK, but now only once instead of 
being duplicated.


I also have this in my init.el:

  (setq org-log-done 'time)

Could this be conflicting with "DONE(x!)" in org-todo-keywords?

Best regards,

Alan


On 7/7/21 11:50 AM, Alan Ristow wrote:
I recently updated org from 9.3 (release_9.3) to 9.4.6 (9.4.6-gfdb98a) 
and observed several changes in behavior when marking recurring tasks 
as DONE. I have not found reports of anything similar via Google or 
the mailing list archives, so rather than a bug it might be a package 
conflict or a configuration issue; in any case, I am having a really 
tough time figuring it out and I hope somebody here might be able to 
give me some pointers.


I use straight.el for package management and as part of this update I 
had to switch from using org-plus-contrib to using org-contrib. 
Normally, straight.el would make it easy for me to go back to my old 
configuration -- I have the lockfile with all the package versions -- 
but because of the movement in org repos and the change from 
org-plus-contrib to org-contrib, I am running into difficulty doing 
that, which probably contributes to my difficulties in troubleshooting.



EXPECTED (FORMER) BEHAVIOR

Suppose I have a task that looks like this:

** TODO Daily review
   SCHEDULED: <2021-07-07 Wed .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-06 Tue 10:03]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

I then do the following:

1. Move the cursor to the TODO line and mark it DONE (t-x in agenda
   view, C-t x in the file buffer).
2. The scheduled date is updated to the next recurrence, and the
   current time is recorded in the LAST_MODIFIED property drawer and in
   the LOGBOOK.

After, the task looks like this:

** TODO Daily review
   SCHEDULED: <2021-07-08 Thu .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-07 Wed 11:18]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

I get the same result when the task is marked as a habit and also when 
I bulk-process tasks from the agenda view using org-agenda-bulk-action.



ACTUAL (CURRENT) BEHAVIOR

I have observed two changes in behavior since updating to org 9.4.6 
and org-contrib.


First, if I do exactly the same as above, the time of completion is 
logged twice:


** TODO Daily review
   SCHEDULED: <2021-07-08 Thu .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-07 Wed 11:18]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

Second, if I bulk-process a habit via org-agenda-bulk-action, the task 
is simply marked DONE. Bot the recurrence and the LAST_REPEAT field 
are ignored, but the time stamp is only entered into the LOGBOOK once:


** DONE Walk
   CLOSED: [2021-07-07 Wed 11:26] SCHEDULED: <2021-07-07 Wed .+1d>
   :PROPERTIES:
   :STYLE:  habit
   :LAST_REPEAT: [2021-07-06 Tue 15:33]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:26]
   - State "DONE"   from "TODO" [2021-07-06 Tue 15:33]
   :END:


MY CONFIGURATION

The extensions to org that I load are: org-super-agenda, 
org-superstar, org-capture, org-tempo, org-checklist, org-habit, 
helm-org-rifle, org-drill, ox-pandoc, org-make-toc, org-ql, org-roam, 
org-journal, org-ref, org-ref-helm-bibtex, and org-roam-bibtex. All 
are the latest versions accessible to straight.el.


My init.el includes the following:

  (setq org-log-done 'time
    org-log-redeadline 'time
    org-log-reschedule 'time
    org-log-into-drawer t
org-log-state-notes-insert-after-drawers nil)
  (setq org-todo-keywords
    '((sequence "TODO(t)" "NEXT(n)" "STARTED(s)" "WAITING(w@/!)" 
"|" "DONE(x!)" "DELEGATED(

4 otc meds

[Jude DaShiell]

I am planning a table to show re-order dates for 4 otc meds I take.  They
haven't got the same pill counts and another constraint will be not to
order on weekends.  Since this is intended to show repeating re-order
dates I figure to use formulas with pill counts in particular cells as
repeater items for the dates and have the dates show up vertically down
each four columns.  It will be interesting to see if this works and if it
does, I'll share it with the list since maybe others would be able to use
something like this in future.

Re: org-table: deleting columns not always actualise the formulas.

[Uwe Brauer]

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

> On Wednesday,  7 Jul 2021 at 09:07, Uwe Brauer wrote:
>> Hi
>> 
>> Please consider the following example
>> 
>> #+begin_src elisp

> [...]

>> #+end_src
>> 
>> Now I delete the last columns
>> 
>> But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
>> it should be.

> Confirmed.

Ok so it is a bug.
I will write a but report then.

> One solution, for the moment, is to move the column over first and then
> delete the columns.

> By the way, it would help if you src blocks were org and not elisp as
> the language!

Oops, I was not sure whether this was the right conf, so to be on the
safe side I used elisp, thanks for pointing this out to me.


Off the record: good look tonight. Although


smime.p7s
Description: S/MIME cryptographic signature

[PATCH] worg/org-contrib: fix links to raw files

[Maxim Nikulin]

On 07/07/2021 22:31, Maxim Nikulin wrote:

On 07/07/2021 14:23, Michael Maurer wrote:

On Tue, 6 Jul 2021 at 08:07, Michael Maurer wrote:


in my config, but making a camel case headline does not create a link
when repeating the word in a paragraph. I've also tried activating
org-wikinodes with m-x customize, but no difference.


"The contrib/ directory now lives outside of Org's repository" is 
announced on https://updates.orgmode.org/


Maybe the new repository and the package should be mentioned on the 
install page to avoid confusion.


Even link to the source file on https://orgmode.org/worg/org-contrib/ is 
incorrect. See the patch.
>From 8ef6e13d10c1ecf03fd3d1b49bcfc53fe03598c7 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Wed, 7 Jul 2021 23:02:56 +0700
Subject: [PATCH] org-contrib/index.org: update org-contrib raw file links

Contrib were removed from the main repository, new location is
https://git.sr.ht/~bzg/org-contrib/
See https://orgmode.org/list/874kf4fanb@gnu.org/
---
 org-contrib/index.org | 113 +-
 1 file changed, 57 insertions(+), 56 deletions(-)

diff --git a/org-contrib/index.org b/org-contrib/index.org
index 0bb3af0c..19a50209 100644
--- a/org-contrib/index.org
+++ b/org-contrib/index.org
@@ -8,6 +8,7 @@
 #+LANGUAGE:   en
 #+CATEGORY:   worg
 #+LINK:   repofile https://code.orgmode.org/bzg/org-mode/raw/master/
+#+LINK:   contribfile https://git.sr.ht/~bzg/org-contrib/blob/master/
 #+HTML_LINK_HOME: https://orgmode.org/worg/
 #+HTML_LINK_UP: ../index.html
 
@@ -37,33 +38,33 @@ hopefully have some documentation.
 - /org-annotate-file.el/ -- annotate a file with org syntax ::
   The annotation is in a separate file, with links back to the
   annotated file.  Written by /Philip Jackson/.
-  [[repofile:contrib/lisp/org-annotate-file.el][Link to raw file]].
+  [[contribfile:lisp/org-annotate-file.el][Link to raw file]].
 
 - /org-bibtex-extras.el/ -- extras for working with org-bibtex entries ::
   Written by /Eric Schulte/.
-  [[repofile:contrib/lisp/org-bibtex-extras.el][Link to raw file]].
+  [[contribfile:lisp/org-bibtex-extras.el][Link to raw file]].
 
 - /org-bookmark.el/ -- support for links to Emacs bookmarks ::
   Written by /Tokuya Kameshima/.
-  [[repofile:contrib/lisp/org-bookmark.el][Link to raw file]].
+  [[contribfile:lisp/org-bookmark.el][Link to raw file]].
 
 - [[file:org-checklist.org][/org-checklist.el/ -- org functions for checklist handling]] ::
   Reset checklists in repeating entries.  Written by /James TD Smith/.
-  [[repofile:contrib/lisp/org-checklist.el][Link to raw file]].
+  [[contribfile:lisp/org-checklist.el][Link to raw file]].
 
 - [[file:org-choose.org][/org-choose.el/ -- decision management for org-mode]] ::
   Org-choose helps documenting a decision-making process by using
   TODO keywords for different degrees of /chosenness/, and by
   automatically keeping a set of alternatives in a consistent state.
   Writen by /Tom Breton/.
-  [[repofile:contrib/lisp/org-choose.el][Link to raw file]].
+  [[contribfile:lisp/org-choose.el][Link to raw file]].
 
 - [[file:org-collector.org][/org-collector.el/ -- collect properties into tables]] ::
   Collect and process properties into a table.
   Written by /Eric Schulte/.
-  [[repofile:contrib/lisp/org-collector.el][Link to raw file]].
+  [[contribfile:lisp/org-collector.el][Link to raw file]].
 
-- [[repofile:contrib/lisp/org-contacts.el][/org-contacts.el/ -- manage contacts (org-plus-contrib)]] ::
+- [[contribfile:lisp/org-contacts.el][/org-contacts.el/ -- manage contacts (org-plus-contrib)]] ::
   Written by /Julien Danjou/, now in Org contrib.
 
 - [[file:org-depend.org][/org-depend.el/ -- TODO dependencies for Org-mode]] ::
@@ -71,41 +72,41 @@ hopefully have some documentation.
   be blocked by the state of another entry.  Also, easily create
   chains of TODO items with exactly one active item at any time.
   Written by /Carsten Dominik/.
-  [[repofile:contrib/lisp/org-depend.el][Link to raw file]].
+  [[contribfile:lisp/org-depend.el][Link to raw file]].
 
 - /org-elisp-symbol.el/ -- Org links to emacs-lisp symbols. ::
   This can create annotated links that exactly point to the definition
   location of a variable of function.
   Written by /Bastien Guerry/.
-  [[repofile:contrib/lisp/org-elisp-symbol.el][Link to raw file]].
+  [[contribfile:lisp/org-elisp-symbol.el][Link to raw file]].
 
 - /org-expiry.el/ -- expiry mechanism for Org entries ::
   Written by /Bastien Guerry/.
-  [[repofile:contrib/lisp/org-expiry.el][Link to raw file]].
+  [[contribfile:lisp/org-expiry.el][Link to raw file]].
 
 - [[file:org-git-link.org][/org-git-link.el/ -- link to files under git version control]] ::
   This package adds new link types to link to specific versions of a
   file, which will be checked out when the link is activated.
   Written by /Reimar Finken/.
-  [[repofile:contrib/lisp/org-git-link.el][Link to raw file]].
+  [[contribfile:lisp/org-git-link.el][Lin

Re: unable to activate org-wikinodes

[Maxim Nikulin]

On 07/07/2021 14:23, Michael Maurer wrote:

On Tue, 6 Jul 2021 at 08:07, Michael Maurer  wrote:


in my config, but making a camel case headline does not create a link
when repeating the word in a paragraph. I've also tried activating
org-wikinodes with m-x customize, but no difference.


Is this deprecated and no longer part of org? I searched the
org-folder for any file resembling wikinodes, but couldn't find
anything.


org-wikinodes.el is a part of org-contrib

"The contrib/ directory now lives outside of Org's repository" is 
announced on https://updates.orgmode.org/


Maybe the new repository and the package should be mentioned on the 
install page to avoid confusion.


https://orgmode.org/list/874kf4fanb@gnu.org/ or
https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00769.html
On 15/05/2021 19:23, Bastien wrote:

Bastien writes:


The files previously stored in the contrib/ directory of Org's repo
now lives here: https://git.sr.ht/~bzg/org-contrib


You can now install org-contrib as a new NonGNU ELPA package:
https://elpa.nongnu.org/nongnu/

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/)]

[Eric S Fraga]

On Wednesday,  7 Jul 2021 at 15:35, Nicolas Goaziou wrote:
> Binding  is frowned upon, because it has higher priority than TAB,
> and also because it doesn't work everywhere, like in terminals.

Ah, okay.  Thank you.

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

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/)]

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


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/)]

[Eric S Fraga]

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.

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

Re: org-table: deleting columns not always actualise the formulas.

[Eric S Fraga]

On Wednesday,  7 Jul 2021 at 09:07, Uwe Brauer wrote:
> Hi
>
> Please consider the following example
>
> #+begin_src elisp

[...]

> #+end_src
> 
> Now I delete the last columns
>
> But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
> it should be.

Confirmed.

One solution, for the moment, is to move the column over first and then
delete the columns.

By the way, it would help if you src blocks were org and not elisp as
the language!

-- 
: 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: Emacs-orgmode Digest, Vol 185, Issue 7

[Eric S Fraga]

Hello,

some advice: in general, it is better to post separate messages for
different questions.  That allows those that have an interested in a
specific aspect of org/emacs to follow and interact.  It also helps to
have a subject line then that describes briefly the topic of the
question.

> - oh, wait. I have an old PC I don't use much (2008 AD -Core 2 Duo). I
> was thinking about using it just for orgmode. Would you recommend me
> an OS?

I run Emacs with org on a little palmtop (well, 2 of them) with Linux so
a Core 2 Duo from 2008 is more than enough if using Linux.  The key
constraint will be memory, with 1 GB being the minimum practical amount
these days in my experience although less can be okay if you're careful.

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: [R example for org-table with ifs]

[Eric S Fraga]

On Wednesday,  7 Jul 2021 at 09:01, Uwe Brauer wrote:
> Out of curiosity do you have an example of using R to generate stuff
> like this.

I don't; sorry.  I don't use R myself directly although my PhD students
do.  Others on this list have quite a bit of experience with R so maybe
somebody else can chime in.

-- 
: 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] Allow tangling to a list of files

[Jacopo De Simoi]

Dear Greg,

Thanks for bringing this up

 Original Message 
On Jul. 7, 2021, 02:56, Greg Minshall < minsh...@umich.edu> wrote:
Vladimir,
> I couldn't find in Org manual how tangling should work if there are
> several source code blocks with the same file name for ':tangle'. The
> Org manual section "15.8 Extracting Source Code" is a bit
> obscure. There are these two sentences
i think what Tim answered is correct. but, i believe the "desired"
approach is to put all those blocks to be tangled to the same file under
a headline with a property drawer containing something like:

:header-args+: :tangle "submsim.jl"

i believe this is for performance of tangling, but possibly the
"multiple source blocks to same :tangle'd file" feature may disappear?
cheers, Greg

Once again, there is a unit test designed to check that different blocks 
tangling to the same file are concatenated in the right order, this without a 
common property drawer. Hence I believe this behavior is not accidental, but a 
wanted feature.

I always understood that this was the expected behavior, to allow descriptions 
to interleave code in a literate config situation.

However, if the documentation is ambiguous, or lacking, then we should probably 
make the docs clear, so that this question does not rise again in the future.

Cheers
Jacopo

Re: convert subtree or nested list to table

[tbanelwebmin]

Hi Matt

Le 05/07/2021 à 21:44, Matt Price a écrit :
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable.  Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!

Maybe you could use builtin Babel
Hereafter you have a starting point
- Give a name to your input Org list
- Process it with Emacs-Lisp (or whatever language you are comfortable
with) to output it as a table


 self contained Org Mode example _

Example of a named list
#+NAME: BBB
- abc
  + 123
  + 456
- def
  + red
  + blue
- ghi
  + big
  + small

Example of converting the named list into a table with Emacs-Lisp
#+begin_src elisp :var bbb=BBB :results table
bbb
#+end_src

#+RESULTS:
| abc | (unordered (123) (456))   |
| def | (unordered (red) (blue))  |
| ghi | (unordered (big) (small)) |
___

Bug: Unexpected behavior marking recurring tasks as DONE

[Alan Ristow]

I recently updated org from 9.3 (release_9.3) to 9.4.6 (9.4.6-gfdb98a) 
and observed several changes in behavior when marking recurring tasks as 
DONE. I have not found reports of anything similar via Google or the 
mailing list archives, so rather than a bug it might be a package 
conflict or a configuration issue; in any case, I am having a really 
tough time figuring it out and I hope somebody here might be able to 
give me some pointers.


I use straight.el for package management and as part of this update I 
had to switch from using org-plus-contrib to using org-contrib. 
Normally, straight.el would make it easy for me to go back to my old 
configuration -- I have the lockfile with all the package versions -- 
but because of the movement in org repos and the change from 
org-plus-contrib to org-contrib, I am running into difficulty doing 
that, which probably contributes to my difficulties in troubleshooting.



EXPECTED (FORMER) BEHAVIOR

Suppose I have a task that looks like this:

** TODO Daily review
   SCHEDULED: <2021-07-07 Wed .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-06 Tue 10:03]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

I then do the following:

1. Move the cursor to the TODO line and mark it DONE (t-x in agenda
   view, C-t x in the file buffer).
2. The scheduled date is updated to the next recurrence, and the
   current time is recorded in the LAST_MODIFIED property drawer and in
   the LOGBOOK.

After, the task looks like this:

** TODO Daily review
   SCHEDULED: <2021-07-08 Thu .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-07 Wed 11:18]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

I get the same result when the task is marked as a habit and also when I 
bulk-process tasks from the agenda view using org-agenda-bulk-action.



ACTUAL (CURRENT) BEHAVIOR

I have observed two changes in behavior since updating to org 9.4.6 and 
org-contrib.


First, if I do exactly the same as above, the time of completion is 
logged twice:


** TODO Daily review
   SCHEDULED: <2021-07-08 Thu .+1d>
   :PROPERTIES:
   :LAST_REPEAT: [2021-07-07 Wed 11:18]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:18]
   - State "DONE"   from "TODO" [2021-07-06 Tue 10:03]
   :END:

Second, if I bulk-process a habit via org-agenda-bulk-action, the task 
is simply marked DONE. Bot the recurrence and the LAST_REPEAT field are 
ignored, but the time stamp is only entered into the LOGBOOK once:


** DONE Walk
   CLOSED: [2021-07-07 Wed 11:26] SCHEDULED: <2021-07-07 Wed .+1d>
   :PROPERTIES:
   :STYLE:  habit
   :LAST_REPEAT: [2021-07-06 Tue 15:33]
   :END:
   :LOGBOOK:
   - State "DONE"   from "TODO" [2021-07-07 Wed 11:26]
   - State "DONE"   from "TODO" [2021-07-06 Tue 15:33]
   :END:


MY CONFIGURATION

The extensions to org that I load are: org-super-agenda, org-superstar, 
org-capture, org-tempo, org-checklist, org-habit, helm-org-rifle, 
org-drill, ox-pandoc, org-make-toc, org-ql, org-roam, org-journal, 
org-ref, org-ref-helm-bibtex, and org-roam-bibtex. All are the latest 
versions accessible to straight.el.


My init.el includes the following:

  (setq org-log-done 'time
    org-log-redeadline 'time
    org-log-reschedule 'time
    org-log-into-drawer t
org-log-state-notes-insert-after-drawers nil)
  (setq org-todo-keywords
    '((sequence "TODO(t)" "NEXT(n)" "STARTED(s)" "WAITING(w@/!)" 
"|" "DONE(x!)" "DELEGATED(d@)")

  (sequence "DEFERRED(f@/!)" "INACTIVE(i@/!)" "|" "CANCELED(c@)")))


Best regards,
Alan

Re: unable to activate org-wikinodes

[Michael Maurer]

On Tue, 6 Jul 2021 at 08:07, Michael Maurer  wrote:
>
> I've put
>
> (setq org-return-follows-link t)
> (custom-set-variables
>  '(org-modules (quote (org-wikinodes)))
>  '(org-return-follows-link t))
>
> in my config, but making a camel case headline does not create a link
> when repeating the word in a paragraph. I've also tried activating
> org-wikinodes with m-x customize, but no difference.
> I'm using org 9.3 and Emacs 27.1 on Win10.

Is this deprecated and no longer part of org? I searched the
org-folder for any file resembling wikinodes, but couldn't find
anything.

And that's after upgrading to the latest Emacs and downloading 9.4.6.

Re: how to avoid 0.0 in an org-table

[Uwe Brauer]

>>> "GM" == Greg Minshall  writes:

Hi Greg


> Uwe,
> your mileage may vary, but try
> : #+TBLFM: $5=vsum($1..$4);f1::$6=min(10,$4)*0.1;%0.1g

> (=man 3 printf= sort of implies that behavior might work for =%g=.)

Oops, thanks a lot I just did not realized the %g option (and I have
used printf in matlab quite a bit, shame on me).

Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

org-table: deleting columns not always actualise the formulas.

[Uwe Brauer]

Hi

Please consider the following example
#+begin_src elisp

| / | <>  |<> | <> |  <> |   <> | <>| <> |  
 |  |  |  |  |  |  | | |
|   | | DMI G | DMNI H | ExNDM I | ExNDNM J | my-result | his-result | 
Check | aux1 | aux2 | aux3 | aux4 | aux5 | aux6 | Res-aux | Weight2 |
|   | Weight: | 1 |0.2 |   1 |  0.1 |   |0.1 |  
 |  |  |  |  |  |  | | 0.1 |
|---+-+---++-+--+---++---+--+--+--+--+--+--+-+-|
|   | user1   | 0 |  0 |  11 |0 | 10.1  |   10.1 | 
OK|0 |0 |  0.0 |  0.1 |   10 |  0.0 |10.1 | |
|---+-+---++-+--+---++---+--+--+--+--+--+--+-+-|
,#+TBLFM: $7=if($3>10,($3-10)*@3$17,0)+ min(10,$3)*@3$3+ min(10,$4)*@3$4 + 
if($5>10,($5-10)*@3$17,0)+min(10,$5)*@3$5 +@3$6*$6;f1::$9=if("$7" == "$8", OK, 
NO)::$10=if($3>10,($3-10)*@3$17,0);f1::$11=min(10,$3)*@3$3;f1::$12=min(10,$4)*@3$4;f1::$13=if($5>10,($5-10)*@3$17,$5);f1::$14=min(10,$5)*@3$3;f1::$15=@3$6*$6;f1::$16=vsum($10..$14);f1
#+end_src


Now I delete the last columns

#+begin_src elisp

| / | <>  |<> | <> |  <> |   <> | <>| |
|   | | DMI G | DMNI H | ExNDM I | ExNDNM J | my-result | Weight2 |
|   | Weight: | 1 |0.2 |   1 |  0.1 |   | 0.1 |
|---+-+---++-+--+---+-|
|   | user1   | 0 |  0 |  11 |0 | 10.1  | |
|---+-+---++-+--+---+-|
,#+TBLFM: $7=if($3>10,($3-10)*@3$16,0)+ min(10,$3)*@3$3+ min(10,$4)*@3$4 + 
if($5>10,($5-10)*@3$16,0)+min(10,$5)*@3$5 +@3$6*$6;f1::
#+end_src

But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
it should be.

Is this a *BUG*? I am running emacs and org git master from a couple of
weeks ago.

Regards

Uwe Brauer 

Re: how to avoid 0.0 in an org-table

[Greg Minshall]

Uwe,

your mileage may vary, but try
: #+TBLFM: $5=vsum($1..$4);f1::$6=min(10,$4)*0.1;%0.1g

(=man 3 printf= sort of implies that behavior might work for =%g=.)

cheers, Greg

[R example for org-table with ifs] (was: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx))

[Uwe Brauer]

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

> On Monday,  5 Jul 2021 at 16:48, Uwe Brauer wrote:
>> Well I do that myself basically, but my main problem is now: *formulas*, I
>> have to collaborate with colleagues using excel and I have to work with
>> their formulas in a way or another. 

> Tell them to use R... ;-)

Out of curiosity do you have an example of using R to generate stuff
like this.


#+begin_src elisp
| / | <>  |<> | <> |  <> |   <> | <> | <>  |
|   | | DMI G | DMNI H | ExNDM I | ExNDNM J | Result | Weight2 |
|   | Weight: | 1 |0.2 |   1 |  0.1 || 0.1 |
|---+-+---++-+--++-|
|   | User1   | 0 |  0 |  11 |0 | 10.1   | |
|---+-+---++-+--++-|
#+TBLFM: $7=if($3>10,($3-10)*@3$8,0)+ min(10,$3)*@3$3+ min(10,$4)*@3$4 + 
if($5>10,($5-10)*@3$8,0)+min(10,$5)*@3$5 +@3$6*$6;f1::
#+end_src


smime.p7s
Description: S/MIME cryptographic signature