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

[Allen Li]

Org mode's tag completion commands all use a custom completion function,
which makes it difficult for alternative completion functions to support
well.

Emacs already has a function for reading multiple things,
completing-read-multiple, which can be used for the tag completion use
case.

I have attached a patch for this change, which I have tested manually a
few times and also fixed the existing tests.  I have tested this with
vertico, which claims to strictly follow Emacs's completion API.

>From 933dc914694c14889af86c06ba0a8bbd88a316cf Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Thu, 8 Jul 2021 21:35:34 -0700
Subject: [PATCH] org: Use crm for completing tags

Change various places which use `completing-read' to read tags using a
custom completion function to instead use `completing-read-multiple'
with a completion table instead.

This makes tab completion play better with alternative completion
frameworks such as vertico, selectrum, etc.

`org-change-tag-in-region' only reads a single tag, so it is changed
to use a completion table with `completing-read'.  This also makes it
play better with alternative completion frameworks.

Note that there is still one use for `org-tags-completion-function',
which is for completing tag matches.  Completing tag matches is
different from completing lists of tags since the separators (+, -,
etc) have semantic meaning.  This commit does not address that use
case.

* lisp/org-capture.el (org-capture-fill-template): Changed to use
completing-read-multiple.
* lisp/org.el (org-set-tags-command): Changed to use
completing-read-multiple.
(org-change-tag-in-region): Changed to use a simple completion table.
* testing/lisp/test-org.el (test-org/set-tags-command): Fixed tests.
* etc/ORG-NEWS (Tag completion now uses =completing-read-multiple=):
Added news.
---
 etc/ORG-NEWS |  6 +
 lisp/org-capture.el  | 12 +-
 lisp/org.el  | 18 +--
 testing/lisp/test-org.el | 50 
 4 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3f3971961..719ac3547 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -409,6 +409,12 @@ The function does not allow for a third optional parameter anymore.
 If a babel src block produces a raw LaTeX environment, it will now be
 recognised as a result, and so replaced when re-evaluated.
 
+*** Tag completion now uses =completing-read-multiple=
+
+Tag completion now uses =completing-read-multiple= with a simple
+completion table, which should allow better interoperability with
+custom completion functions.
+
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 5ecec6309..c51744680 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -69,6 +69,7 @@
 (declare-function org-table-goto-line "org-table" (N))
 
 (defvar dired-buffers)
+(defvar crm-separator)
 (defvar org-end-time-was-given)
 (defvar org-keyword-properties)
 (defvar org-remember-default-headline)
@@ -1739,12 +1740,11 @@ The template may still contain \"%?\" for cursor positioning."
 			(org-add-colon-after-tag-completion t)
 			(ins (mapconcat
   #'identity
-  (org-split-string
-   (completing-read
-(if prompt (concat prompt ": ") "Tags: ")
-'org-tags-completion-function nil nil nil
-'org-tags-history)
-   "[^[:alnum:]_@#%]+")
+  (let ((crm-separator "[ \t]*:[ \t]*"))
+(completing-read-multiple
+ (if prompt (concat prompt ": ") "Tags: ")
+ org-last-tags-completion-table nil nil nil
+ 'org-tags-history))
   ":")))
 		   (when (org-string-nw-p ins)
 			 (unless (eq (char-before) ?:) (insert ":"))
diff --git a/lisp/org.el b/lisp/org.el
index 4fd8b6fa6..ed3ee3a1c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -201,6 +201,8 @@ Stars are put in group 1 and the trimmed body in group 2.")
 ;; load languages based on value of `org-babel-load-languages'
 (defvar org-babel-load-languages)
 
+(defvar crm-separator)  ; dynamically scoped param
+
 ;;;###autoload
 (defun org-babel-do-load-languages (sym value)
   "Load the languages defined in `org-babel-load-languages'."
@@ -12054,12 +12056,14 @@ in Lisp code use `org-set-tags' instead."
 		  inherited-tags
 		  table
 		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
-		   (let ((org-add-colon-after-tag-completion (< 1 (length table
-		 (org-trim (completing-read
-"Tags: "
-#'org-tags-completion-function
-nil nil (org-make-tag-string current-tags)
-'org-tags-history)))
+		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
+ (crm-separator "[ \t]*:[ \t]*"))
+		 (string-join (completing-read-multiple
+			   "Tags: "
+			   org-last-tags-completion-table
+			   nil nil 

Re: org-mode-map binds [tab]

[Stefan Monnier]

> Does outline.el need to be fixed too?
[...]
> ——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'.")

Very much so, indeed, thanks.
I just pushed that change to `master`.


Stefan

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

[William Denton]

On 8 July 2021, Bruce D'Arcus wrote:


And the implementation challenges raised by John Kitchin and Joost
Kremers (namely the candidate list is different) make this better to
deal with using a different mechanism.

As a package developer that supports org-cite, I really don't want to
be worrying about internal references and such.

And as a user, I don't see the benefit of doing so.

Effectively, these seem more like org internal links.


I agree with all this.  Personally, I'd never expect a citation system like this 
to handle internal references.  The way librarians think about citations and 
referencing, these are different.



Bill

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

Re: breakpoint in debugging org-table formulas

[Nick Dokos]

Uwe Brauer  writes:

> Hi 
>
> I just started to use the formula debugger
> (org-table-toggle-formula-debugger) which is quite nice.
>
> However for large tables with a lot of rows it would be more
> convenient to use breakpoints and not start just in the first row.
>
> I can't find any reference for that. 
>
> It is not implemented?
>
I've often wished for the same, but I don't think it's implemented.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: how to document/comment a complex org table formula

[Nick Dokos]

Uwe Brauer  writes:

 "GdaO" == General discussions about Org-mode  writes:
>
>> Limbic answer : 
>>   - create an emacs-lisp function doing what you want
>>   - comment /ad libitum/
>>   - call this function in your spreadsheet.
>
> I hoped such a function already existed and somebody would point it out
> to me (I searched the package-list-package list but nothing came up)
>

IIUC, the function would replace the formula, so it's really the
formula in a different guise, similar to what Eric F. was talking
about: implementing the formula as a source block. Both of them put
the code in some other place, where there is space to add comments.
IOW, it's not a general-purpose function. But I may be misconstruing
what Emmanuel was suggesting.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: A requires/provides approach to linking source code blocks

[Tim Cross]

Marko Schuetz-Schmuck  writes:

> [[PGP Signed Part:Undecided]]
> Dear All,
>
> AFAIU in the current support for literate programming I can establish
> sequence between blocks by either tangling the entire file whereby the
> blocks are written to the source code file in the sequence in which they
> appear in the org-mode file or I can name the blocks and use noweb
> linking to explicitly state the precise sequence in which the blocks
> appear in the source code file.
>
> I would find it useful to have a more declarative way for specifying
> sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to
> capture dependency and then have the exporter compute a sequence
> satisfying these. I would think that this makes the maintenance of the
> dependencies more convenient.
>
> I'd be interested in feedback on the idea.
>
> Please include my email address in the reply as I am not subscribed to
> the list.
>

My concern here is with the additional complexity. This is already a
somewhat complex aspect of org mode and the behaviour you describe can
effectively be done using noweb, although as you say, not as
declarative in style.

I'm not sure the added complexity is worth the additional maintenance
overhead and I would be concerned regarding how much confusion this
could cause i.e. someone uses both noweb and declarative
provide/require. These additions are also likely to hamper any efforts
to improve performance - a topic which comes up on a fairly regular
basis. 

This could just be me, but recently, I'm becoming very concerned about
the growth of additional features and options in org mode. Many of the
new things being requested are for relatively narrow use cases and
represent functionality which can largely be achieved with existing
features. At the same time, there also seems to be a growing
frequency in patches which introduce regression bugs and patches to fix
patches.

This is all beginning to feel like we are running very close to the
tipping point at which time we will have something that is so complex
that only a very few people are able to maintain the code base and keep
the system stable. New maintainers are discouraged because of the code
complexity. We could end up in a position where really important issues
cannot be addressed or addressed in a timely manner because of the
overall complexity of the code base and time it takes to fix and test
and dependence on a very few number of maintainers who are already
swamped with work. 

At some point, I think we may want to consider a temporary freeze on new
functionality and spend a few months just focusing on bug fixes and code
base improvements or re-factoring. It might also be worthwhile providing
some guidelines or criteria/procedures for assessing proposed new
features to avoid a perception of new features being accepted/rejected
based on personality, loudness of voice or some other real or perceived
and irrelevant basis.


-- 
Tim Cross

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

[Tim Cross]

Marco Wahl  writes:

> Marco Wahl  writes:
>
>> Marco> Please recall that only empty attachment directories would be
>> Marco> removed, so removal of a directory--and in particular one
>> Marco> that existed before its interpretation as Org
>> Marco> attachment--wouldn't be a big deal AFAICS.
>>
>> Tim> Not as confident here. I can imagine workflows and other
>> Tim> external scripts which might expect a specific directory
>> Tim> structure that could be broken if a directory was removed (even
>> Tim> when empty). Hence my suggestion it needs to be something you
>> Tim> can turn off.
>>
>> Tim> Likely this is something which should be controllable via a
>> Tim> custom setting?
>>
>> Marco> To be honest I'd rather not make another customizable thing
>> Marco> out of it to keep the overall complexity low.
>> Marco> 
>> Marco> OTOH we could easily introduce e.g. customizable
>> Marco> org-attach-delete-empty-dirs-on-sync.
>>
>> Tim> Appreciate the problem with far too many customization options,
>> Tim> but when it comes to software 'automatically' doing something,
>> Tim> like removal of an empty directory, especially when it might
>> Tim> not have been responsible for creation of the directory, it is
>> Tim> better to provide some way to allow the user to turn off the
>> Tim> behaviour. I would default to having it enabled though.
>>
>> Colin> I'm afraid I for one often have empty attach directories
>> Colin> which I leave alone knowing that one day soon - sometimes
>> Colin> very soon - they will be used again. Cannot the user be asked
>> Colin> if he wants the directory removed?
>>
>> Thanks Tim and Colin.
>>
>> We could introduce multiple possibilities to choose from.
>>
>> 1. Ask in case of an empty directory if it should be deleted.
>> 2. Don't ask.  Don't touch an empty directory.  (The state now.)
>> 3. Don't ask.  Delete empty directory.
>>
>> We could also make 3. the default setting.
>
> I made a mistake here.
>
> If we do this I vote for option 1. (not 3.) as default (following the
> suggestion by Colin) since it is the most interactive variant.  If the
> question gets annoying the user can switch to one of the other options.
>

That seems quite resonable to me. 

-- 
Tim Cross

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

[Marco Wahl]

Marco Wahl  writes:

> Marco> Please recall that only empty attachment directories would be
> Marco> removed, so removal of a directory--and in particular one
> Marco> that existed before its interpretation as Org
> Marco> attachment--wouldn't be a big deal AFAICS.
>
> Tim> Not as confident here. I can imagine workflows and other
> Tim> external scripts which might expect a specific directory
> Tim> structure that could be broken if a directory was removed (even
> Tim> when empty). Hence my suggestion it needs to be something you
> Tim> can turn off.
>
> Tim> Likely this is something which should be controllable via a
> Tim> custom setting?
>
> Marco> To be honest I'd rather not make another customizable thing
> Marco> out of it to keep the overall complexity low.
> Marco> 
> Marco> OTOH we could easily introduce e.g. customizable
> Marco> org-attach-delete-empty-dirs-on-sync.
>
> Tim> Appreciate the problem with far too many customization options,
> Tim> but when it comes to software 'automatically' doing something,
> Tim> like removal of an empty directory, especially when it might
> Tim> not have been responsible for creation of the directory, it is
> Tim> better to provide some way to allow the user to turn off the
> Tim> behaviour. I would default to having it enabled though.
>
> Colin> I'm afraid I for one often have empty attach directories
> Colin> which I leave alone knowing that one day soon - sometimes
> Colin> very soon - they will be used again. Cannot the user be asked
> Colin> if he wants the directory removed?
>
> Thanks Tim and Colin.
>
> We could introduce multiple possibilities to choose from.
>
> 1. Ask in case of an empty directory if it should be deleted.
> 2. Don't ask.  Don't touch an empty directory.  (The state now.)
> 3. Don't ask.  Delete empty directory.
>
> We could also make 3. the default setting.

I made a mistake here.

If we do this I vote for option 1. (not 3.) as default (following the
suggestion by Colin) since it is the most interactive variant.  If the
question gets annoying the user can switch to one of the other options.

Sorry for the confusion.

clocktable: is there any ongoing effort on sum by tags funcionality ?

[Pinmacs]

Hi,

I saw a lot of patches and isolated efforts to have the feature of 
summing time by tag on a clocktable (instead of a file)


Is there any ongoing effort or motivation to include it in emacs orgmode?

Cheers,
Pinmacs

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

[Marco Wahl]

Marco> Please recall that only empty attachment directories would be
Marco> removed, so removal of a directory--and in particular one
Marco> that existed before its interpretation as Org
Marco> attachment--wouldn't be a big deal AFAICS.

Tim> Not as confident here. I can imagine workflows and other
Tim> external scripts which might expect a specific directory
Tim> structure that could be broken if a directory was removed (even
Tim> when empty). Hence my suggestion it needs to be something you
Tim> can turn off.

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

Marco> To be honest I'd rather not make another customizable thing
Marco> out of it to keep the overall complexity low.
Marco> 
Marco> OTOH we could easily introduce e.g. customizable
Marco> org-attach-delete-empty-dirs-on-sync.

Tim> Appreciate the problem with far too many customization options,
Tim> but when it comes to software 'automatically' doing something,
Tim> like removal of an empty directory, especially when it might
Tim> not have been responsible for creation of the directory, it is
Tim> better to provide some way to allow the user to turn off the
Tim> behaviour. I would default to having it enabled though.

Colin> I'm afraid I for one often have empty attach directories
Colin> which I leave alone knowing that one day soon - sometimes
Colin> very soon - they will be used again. Cannot the user be asked
Colin> if he wants the directory removed?

Thanks Tim and Colin.

We could introduce multiple possibilities to choose from.

1. Ask in case of an empty directory if it should be deleted.
2. Don't ask.  Don't touch an empty directory.  (The state now.)
3. Don't ask.  Delete empty directory.

We could also make 3. the default setting.

Re: Bug: Unexpected behavior marking recurring tasks as DONE

[Bhavin Gandhi]

Hello Alan,

Thank you for sharing a detailed description.

On Wed, 7 Jul 2021 at 23:52, Alan Ristow wrote:
> […]
> >
> > 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:
> >

I think this is same issue as reported in this bug report:
https://orgmode.org/list/87o8c8xp9b@gmail.com/

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

I was not able to reproduce this correctly, I will try to reproduce it
again later.

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

[Jacopo De Simoi]

Hi Doctor,

 It's good to have such constructive discussion here.

I like your approach to tangle based on tags.  I accomplish more or less the 
same in this (unfinished) literate config for zshrc

https://gist.github.com/85c9b9c9ab151c5fd35bd761ef6ef569

Here the function `org-tags-to-filenames' simply fetches the list of tags and 
returns a list of filenames corresponding to the tags.  Each block is then 
tangled to each file in the returned list (using the patch under discussion)

Best
 J
‐‐‐ Original Message ‐‐‐

On Thursday, July 8th, 2021 at 12:41 PM, Trust me I am a Doctor 
 wrote:

> Hi,
>
> I have no particular opinion for the patch proposed but wanted to share
>
> with you some reflections I had on the subject to use one org file to
>
> tangle to multiple setup.
>
> I use abundantly virtual machines and my emacs configurations have many
>
> bits that I don't want everywhere, be it a mail setup, a rss setup, or
>
> extra languages setup ... etc.
>
> It is not exactly the same usage, I do not tangle different versions in
>
> one pass, I tangle a version at a time, and take care of installing it
>
> in the right place later.
>
> Naively I started to use the header's tags to tangle blocks. I thought
>
> because there was already in place a query syntax for the tags it
>
> may been interesting to use that.
>
> You can see attached a proto of a tangle function that accept tags
>
> specification and that will only tangle the blocks of the headings
>
> matching this specification; and some utilities that I use with it.
>
> However I must say that solution is quite simplistic. It effectively
>
> allow me to filter dynamically what I tangle from my files, but I cannot
>
> rely on it to specify elegantly, eg, complex dependencies between
>
> packages.
>
> At some point I wished to use org-properties to abstract some logics
>
> from Elisp to org, and then forget about I always have something else to
>
> tweak ...
>
> --

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

[Trust me I am a Doctor]

Hi,

I have no particular opinion for the patch proposed but wanted to share
with you some reflections I had on the subject to use one org file to
tangle to multiple setup.

I use abundantly virtual machines and my emacs configurations have many
bits that I don't want everywhere, be it a mail setup, a rss setup, or
extra languages setup ... etc.

It is not exactly the same usage, I do not tangle different versions in
one pass, I tangle a version at a time, and take care of installing it
in the right place later.

Naively I started to use the header's tags to tangle blocks. I thought
because there was already in place a query syntax for the tags it
may been interesting to use that.

You can see attached a proto of a tangle function that accept tags
specification and that will only tangle the blocks of the headings
matching this specification; and some utilities that I use with it.



tag-tangler.el
Description: tag-tangler.el

However I must say that solution is quite simplistic. It effectively
allow me to filter dynamically what I tangle from my files, but I cannot
rely on it to specify elegantly, eg, complex dependencies between
packages.

At some point I wished to use org-properties to abstract some logics
from Elisp to org, and then forget about I always have something else to
tweak ...

--

A requires/provides approach to linking source code blocks

[Marko Schuetz-Schmuck]

Dear All,

AFAIU in the current support for literate programming I can establish
sequence between blocks by either tangling the entire file whereby the
blocks are written to the source code file in the sequence in which they
appear in the org-mode file or I can name the blocks and use noweb
linking to explicitly state the precise sequence in which the blocks
appear in the source code file.

I would find it useful to have a more declarative way for specifying
sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to
capture dependency and then have the exporter compute a sequence
satisfying these. I would think that this makes the maintenance of the
dependencies more convenient.

I'd be interested in feedback on the idea.

Please include my email address in the reply as I am not subscribed to
the list.

Best regards,

Marko


signature.asc
Description: PGP signature

[PATCH] bad table formula recorded in some cases

[tbanelwebmin]

Small bug, small fix.

Suppose we have a table embedded in a begin-end block.

#+begin: aaa :param value
| a | b |
| a | b |
#+end:

Suppose we want to add a formula, with C-c =
We end up with an incorrect result:

#+begin: aaa :param value
| a | 33 |
| a |  b |
 :param value $2=33
#+end:

The fix: in org-table.el, line 2177, change
  (insert (or (match-string 2) "#+TBLFM:")))
to
  (insert "#+TBLFM:"))

Then we get the correct result:

#+begin: aaa :param value
| a | 33 |
| a |  b |
#+TBLFM: $2=33
#+end:
 
Why? Because (match-string 2) is supposed to refer to the (looking-at)
instruction 7 lines above. But (match-string 2) is in the else branch,
which means that (looking-at) failed. Therefore (match-string 2) returns
garbage.

Thanks to Uwe Brauer for pointing to this bug.

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

[Eric S Fraga]

Thank you for both the links and the suggestions!  Very helpful.  I will
start playing. :-)

-- 
: 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: [PATCH] Do not throw error when parameter of :tangle is not a string

[Jacopo De Simoi]

Hi Sébastien,

‐‐‐ Original Message ‐‐‐

On Thursday, July 8th, 2021 at 4:44 AM, Sébastien Miquel 
 wrote:

> Hi,
>
> Jacopo De Simoi writes:
>
> > in the current master branch, if the parameter :tangle of a src block is not
> >
> > a string, tangling fails by throwing an error when calling `file-name- 
> > directory' This patch checks if the parameter is a string before calling` 
> > file-name-directory'.
> >
> > This makes construct such as :tangle (when condition-applies "filename") 
> > work
> >
> > again (as they did a few versions ago…)
>
> Thanks for the patch. It looks good to me (had to run `dos2unix' to apply).

Dos2unix? I'll make sure it doesn't happen again. It might have to do with 
having sent the patch from Android.

>To clarify, it fixes` :tangle (when condition-applies "filename")' when the
>
> condition doesn't apply, such as `(when nil "filename")'.

Yes, I will update the commit message and resubmit. Thanks!
>
> Regards,
>
> -
>
> Sébastien Miquel

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

[Nicolas Goaziou]

Timothy  writes:

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

I'm still lost, sorry.

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

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

is already exported as

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

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

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

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

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

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

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 9:43 AM Timothy  wrote:
>
> Hi Nicolas,
>
> > At this point, I don’t have enough understanding of the problem to have
> > an opinion. IIUC, your example does not even mention citations. How
> > should it be used, what should be the output in LaTeX, and in UTF-8
> > export? This is not clear to me.
> >
> > What can I say however is: if this feature implies to change, or extend,
> > syntax, then it is /de facto/ a blocker for the merge, and needs to be
> > sorted out.
>
> This very much depends on how you view references vs citations. I personally
> think of references as in-text citations (i.e. you’re citing other bits of the
> very same document), but I doubt this is a common view (as suggested by other
> replies).

I'm glad you raised the question, even if it is a bit late. But I
indeed don't think your view is common :-)

I decided to take a look at what a canonical guide like Chicago Manual
of Style says about this.

They call these "text references" (though confusingly, they use the
word "references" when discussing citations too).

For example, there are headings like "3.9: Text references to numbered
illustrations". or "2.30: Formatting text references and callouts to
tables and illustrations".

And then descriptions like "A text reference is addressed to the
reader (“see table 5,” or “fig. 3.2”) and will appear in the published
version."

Here's some stuff from APA, though they don't go into references much.

https://apastyle.apa.org/style-grammar-guidelines/tables-figures/figures

And finally, FWIW, MS Word and Open/LibreOffice implement support for
this via "cross-references":

https://guides.lib.umich.edu/c.php?g=283073=1888264

https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Using_automatic_cross-references

So they may be similar, but are not the same.

And the implementation challenges raised by John Kitchin and Joost
Kremers (namely the candidate list is different) make this better to
deal with using a different mechanism.

As a package developer that supports org-cite, I really don't want to
be worrying about internal references and such.

And as a user, I don't see the benefit of doing so.

Effectively, these seem more like org internal links.

Bruce

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

[Timothy]

Hi Nicolas,

> At this point, I don’t have enough understanding of the problem to have
> an opinion. IIUC, your example does not even mention citations. How
> should it be used, what should be the output in LaTeX, and in UTF-8
> export? This is not clear to me.
>
> What can I say however is: if this feature implies to change, or extend,
> syntax, then it is /de facto/ a blocker for the merge, and needs to be
> sorted out.

This very much depends on how you view references vs citations. I personally
think of references as in-text citations (i.e. you’re citing other bits of the
very same document), but I doubt this is a common view (as suggested by other
replies).

To try to lay out what one may expect with references, I’d think some support in
Org (without org-ref et. al) would be good (at least for exporting) — but I’m
not sure what a good for would be.

I think it could be treated similarly to citations, given a variant syntax like
[] or even just be added as a way of exporting links to named
figures/tables (i.e. ).

It’s a bit late to bring this up, but in case this should come under the
citation umbrella I thought I should.

Lastly, an example of what I’d expect when exporting to ascii (with three
example syntaxes):

┌
│ #+name: sometab
│ #+caption: Some table
│ | a | b |
│ | c | d |
│ 
│ Hey, look at [[sometab]]. (or)
│ Hey, look at [cite:#sometab]. (or)
│ Hey, look at [ref:sometab].
└

┌
│ ━━
│  a  b 
│  c  d 
│ ━━
│ Table 1: Some table
│ 
│ Hey, look at Table 1.
└

I hope this clears up what I was thinking.

All the best,
*Timothy*

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

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 7:46 AM Nicolas Goaziou  wrote:

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

Okay, I see now.

So `org-cite-supported-styles' returns what it sounds like; a list of styles.

((("author" "a")
  ("caps" "c"))
 (("noauthor" "na")
  ("bare" "b"))
 (("nocite" "n"))
 (("note" "ft")
  ("caps" "c")
  ("bare-caps" "bc"))
 (("numeric" "nb"))
 (("text" "t")
  ("caps" "c")
  ("bare-caps" "bc"))
 (("nil")
  ("caps" "c")
  ("bare-caps" "bc")
  ("bare" "b")))

 `org-cite-basic--complete-style' is "trivial" just in the sense it
only supports styles (not sub-styles), and one can imagine adding
annotations to make it easier for users to know what a given choice
will result in.

But that's not for you to worry about, or for oc-basic.

I'll think about it; not sure what the best path for a more
feature-full alternative would be ATM.

Bruce

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

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 8:48 AM Eric S Fraga  wrote:
> ... I have lost track of what is going on in the emacs-sphere
> when it comes to completion frameworks.  I use ivy/counsel.  Is there
> somewhere a good summary of the state of play?  Would I wish to move to
> another framework?

You're not the only one. There's been a ton of activity on this new
generation of completing-read-based completion packages the past
year+.

And what's a bit difficult to grok initially is these are decoupled
packages that work together, which gives users more choice, but can
also be confusing.

Probably the best summary is on the Selectrum repo README. But there's
a lot there, so it might be a bit much.

I have also tried to summarize it on my README in a more focused way.

Note that that selectrum repo has some test scripts where you can kick
the tires with different options, using emacs -Q.

https://github.com/raxod502/selectrum/tree/master/test

I use an adapted version of those in my repo, so in that case you can
just do ./run.sh.

If you want to dive in, my suggestion is install and configure the
following, and experiment.

1. vertico and selectrum (completion UI; I prefer vertico these days,
but they're really similar, and they don't conflict if you have both
installed)
2. orderless (completion-style)
3. consult (counsel-like commands, and now enhanced multi-selection)
4. embark (contextual actions)

That should give you similar experience to what you have now, in a
more modular approach.

Bruce

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

[Eric S Fraga]

On Thursday,  8 Jul 2021 at 07:41, Bruce D'Arcus wrote:
> This was very helpful, so I just added a commit making use of it.
>
> https://github.com/bdarcus/bibtex-actions#org-cite

Bruce,

this looks very good.

I know this is potentially off-topic for this list (not completely:
searching for references to cite is an integral part of my writing
activity) but I have lost track of what is going on in the emacs-sphere
when it comes to completion frameworks.  I use ivy/counsel.  Is there
somewhere a good summary of the state of play?  Would I wish to move to
another framework?

Thank you,
eric

-- 
: 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: [wip-cite-new] Merging tomorrow?

[Eric S Fraga]

Okay, thank you.  I'll have to train myself to use C-c ' in more
situations (as I didn't know it would work on #+include etc. lines).

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

[Christian Moe]

Hi, Matt,

Here's a version of this with a bit more processing.

Define this somewhere in your document

#+NAME: list2table
#+BEGIN_SRC elisp :var order="columns"
  (let (longest)
(setq data (map 'list 'flatten data))
(setq data (map 'list (lambda (x) (seq-difference x '(unordered ordered))) 
data))
;; Pad out lists to equal length
(setq longest (seq-max (map 'list 'length data)))
(setq data
  (map 'list
   (lambda (l)
 (append l (make-list (- longest (length l)) "")))
 data))
;; Order by columns or rows
(if (string= order "columns")
(apply #'mapcar* #'list data) ; transpose
  data))
#+END_SRC

Here is an example list to try it out with:

#+NAME: testlist
- Letters
  1. a
  2. b
  3. c
- Roman numerals
  1. i
  2. ii
  3. iii
- Greek letters
  1. alpha
  2. beta
  3. gamma

Now you can call the src block, passing the name of the list to the
"data" variable.

#+CALL: list2table(data=testlist)

#+RESULTS:
| Letters | Roman numerals | Greek letters |
| a   | i  | alpha |
| b   | ii | beta  |
| c   | iii| gamma |

The default here is that each top item and its sublist forms a column.

To get rows instead, pass order="rows" (or anything other than
order="columns" really):

#+CALL: list2table(data=testlist, order="rows")

#+RESULTS:
| Letters| a | b| c |
| Roman numerals | i | ii   | iii   |
| Greek letters  | alpha | beta | gamma |

You can use numbered or unnumbered lists. Sublists don't strictly have
to be the same length - the code pads them out to equal length with the
empty string before transposing. However, I would strongly recommend
using numbered sublists of the same length (with blank items as needed),
so you can make sure that items line up correctly.

If you want column headers or rownames, you will need to take care of
that manually before exporting. Using ":colnames yes" will lead to
errors when the source is a list. Might be away to hack org-babel to get
around this but I don't know how. (The only automatic solution I can
think of would be by naming the calls in an unexported section and
referencing them with another layer of calls in the exported section,
using a src block that only passes the data on with :colnames yes. But
that's fiddly.)

Will this work for you?

Yours,
Christian


Matt Price writes:

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

Re: STOP this patch for now.

[Christian Hopps]

stardiviner  writes:


On Jul 8, 2021, at 4:59 PM, Christian Hopps 
wrote:

It may eventually be incorporated into the very popular emacs-mac
port (railwaycat tap in homebrew); however, it will probably not
be incorporated into the nextstep/emacs main code. I started
looking at doing a version for the mainline code, but it’s hard
to get motivated b/c using that version of emacs on OS X is a
pretty sub-par experience.


Thanks for your work on this support. I found upstream is less
active. Don’t know when will be merged.



I only commented on this b/c I think you might are disabling
notifications-notify which work great with my code changes, and
using something else if you see Darwin OS, and that will break my
native “Just Works” support for notifications, which again may
end up on many peoples machines. I would ask that the patch be
modified in a way that didn’t break native support if present
before it was accepted.

Also as you can see by the multiple patches you’ve submitted
there’s really no good answer for an external notifier, so
whatever you pick is probably going to be wrong for someone I
guess.


Yes, this troubled my too. Currently no good solution. I will stop
this patch for now. Wait for upstream emacs-mac port support. Hope it
will be arrived in at leas half of year.


You could add a comment to the pull-request in support of merging. :)

https://bitbucket.org/mituharu/emacs-mac/pull-requests/10

FWIW, if you are currently using the railwaycat tap in homebrew you can just 
switch to my tap and you'll get the support right now. It should be just as 
easy to install.

Thanks,
Chris.






If this patch is going to be accepted I would ask that it

1) be conditional (disable-able with a variable)
2) do the check for the custom installed external notifier and if
not present then fallback to using the emacs supplied
notifications-notify
3) not restrict notifications-notify to gnu/linux only.

That way people that have already developed solutions for this
won’t have them broken.

Thanks,
Chris.


On Jul 7, 2021, at 8:00 PM, stardiviner 
wrote:

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 <
cho...@chopps.org> 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 <
numbch...@gmail.com> 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 <
cho...@chopps.org> 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  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 <
theophil...@gmail.com> wrote:


stardiviner  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
 

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

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 7:46 AM Nicolas Goaziou  wrote:

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

OK, I'll take a closer look at that.

Bruce

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

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

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

Good question.

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

In this situation, I think

  #+bibliography: somefile.bib

is closer from

  #+include: somefile.org

or

  #+setupfile: config.org

than it is from

  [[file:somefile.org]]

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

Regards,
-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

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

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

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

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

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

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

Regards,
-- 
Nicolas Goaziou

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

[Eric S Fraga]

On Thursday,  8 Jul 2021 at 02:17, Nicolas Goaziou wrote:
> I think the "wip-cite-new" branch is in good shape now. As
> a consequence, I'd like to merge it tomorrow.

Yes please!  I've been using it on and off (having to switch branches)
for some time now and it is working very well.  It needs to be in master
*now*!

One point, however:

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

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

Not a show-stopper, more of a puzzling choice (to me).

Thank you for all the work on this new feature, in any case!

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

This was very helpful, so I just added a commit making use of it.

https://github.com/bdarcus/bibtex-actions#org-cite

So same org-cite-insert behavior as oc-basic, but using
bibtex-actions-read for the completion.

Bruce

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

[Eric S Fraga]

On Thursday,  8 Jul 2021 at 11:47, Timothy wrote:
> wip-cite-new deals with citing from bibliographies, but I don't think it
> deals with within-document referencing --- should it?

Are these not orthogonal activities?  Doesn't org already support
in-document references?  I may be missing something but what you have
described has nothing to do with citations.

-- 
: 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: [wip-cite-new] Merging tomorrow?

[John Kitchin]

My intuition is that crossrefs are separate from the citations. In org-ref,
they are separate link types like ref:xxx, pageref:xxx. eqref:xxx, etc.
They also use a different source of candidates than cites do.

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 Thu, Jul 8, 2021 at 7:16 AM Bruce D'Arcus  wrote:

> On Thu, Jul 8, 2021 at 6:26 AM Nicolas Goaziou 
> wrote:
> >
> > Hello,
> >
> > Timothy  writes:
> >
> > > Bruce D'Arcus  writes:
> > >
> > >>> wip-cite-new deals with citing from bibliographies, but I don't
> think it
> > >>> deals with within-document referencing --- should it?
> > >
> > >> 1. Should it?
> > >> 1. Maybe.
> > >
> > > I feel like it would fit. With everything that's been done for
> > > citations, this feels like it may be a rather minor addition (or at
> > > least this is what I hope).
> > >
> > >> 2. Can it? Could the design be extended to include internal
> referencing?
> > >> 2. I think so. You'd just need a way to include internal targets in
> > >> addition to the citation-references (keys); for illustration,
> > >> something like [cite:#some-if].
> > >
> > > I can't claim to have thought about this that much either, but
> something
> > > like [cite:#some-fig] would seem to fit.
> > >
> > >> 3. If yes to both, should that hold back merger now?
> > >> 3. No.
> > >
> > > I don't think this should hold up the merge either, but it's relevant
> in
> > > the overall nature of the feature and perhaps could be shoehorned in
> > > following the merge? I feel like this is one small quite simple case
> and
> > > most of the thinking required has already been done. I'm not sure
> > > though, I'd go with whatever Nic's thought are on this.
> >
> > At this point, I don't have enough understanding of the problem to have
> > an opinion. IIUC, your example does not even mention citations. How
> > should it be used, what should be the output in LaTeX, and in UTF-8
> > export? This is not clear to me.
> >
> > What can I say however is: if this feature implies to change, or extend,
> > syntax, then it is /de facto/ a blocker for the merge, and needs to be
> > sorted out.
>
> As I was hinting, I don't know this area well either.
>
> I think the first question is the "should" one; whether this is
> in-scope of this module.
>
> I wasn't sure, so said "maybe".
>
> Joost says "no."
>
> In latex, such internal references are not citations though; they use
> a different mechanism.
>
> Does that not suggest, Timothy, that this might be out-of-scope for
> this module; that Joost is right?
>
> Bruce
>
>

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

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 6:26 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Timothy  writes:
>
> > Bruce D'Arcus  writes:
> >
> >>> wip-cite-new deals with citing from bibliographies, but I don't think it
> >>> deals with within-document referencing --- should it?
> >
> >> 1. Should it?
> >> 1. Maybe.
> >
> > I feel like it would fit. With everything that's been done for
> > citations, this feels like it may be a rather minor addition (or at
> > least this is what I hope).
> >
> >> 2. Can it? Could the design be extended to include internal referencing?
> >> 2. I think so. You'd just need a way to include internal targets in
> >> addition to the citation-references (keys); for illustration,
> >> something like [cite:#some-if].
> >
> > I can't claim to have thought about this that much either, but something
> > like [cite:#some-fig] would seem to fit.
> >
> >> 3. If yes to both, should that hold back merger now?
> >> 3. No.
> >
> > I don't think this should hold up the merge either, but it's relevant in
> > the overall nature of the feature and perhaps could be shoehorned in
> > following the merge? I feel like this is one small quite simple case and
> > most of the thinking required has already been done. I'm not sure
> > though, I'd go with whatever Nic's thought are on this.
>
> At this point, I don't have enough understanding of the problem to have
> an opinion. IIUC, your example does not even mention citations. How
> should it be used, what should be the output in LaTeX, and in UTF-8
> export? This is not clear to me.
>
> What can I say however is: if this feature implies to change, or extend,
> syntax, then it is /de facto/ a blocker for the merge, and needs to be
> sorted out.

As I was hinting, I don't know this area well either.

I think the first question is the "should" one; whether this is
in-scope of this module.

I wasn't sure, so said "maybe".

Joost says "no."

In latex, such internal references are not citations though; they use
a different mechanism.

Does that not suggest, Timothy, that this might be out-of-scope for
this module; that Joost is right?

Bruce

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

[Nicolas Goaziou]

Hello,

Timothy  writes:

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

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

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

Regards,
-- 
Nicolas Goaziou

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

[Timothy]

Bruce D'Arcus  writes:

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

> 1. Should it?
> 1. Maybe.

I feel like it would fit. With everything that's been done for
citations, this feels like it may be a rather minor addition (or at
least this is what I hope).

> 2. Can it? Could the design be extended to include internal referencing?
> 2. I think so. You'd just need a way to include internal targets in
> addition to the citation-references (keys); for illustration,
> something like [cite:#some-if].

I can't claim to have thought about this that much either, but something
like [cite:#some-fig] would seem to fit.

> 3. If yes to both, should that hold back merger now?
> 3. No.

I don't think this should hold up the merge either, but it's relevant in
the overall nature of the feature and perhaps could be shoehorned in
following the merge? I feel like this is one small quite simple case and
most of the thinking required has already been done. I'm not sure
though, I'd go with whatever Nic's thought are on this.

Whichever way this diversion goes, I'm excited to see wip-cite-new merged!

-- 
Timothy

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

[Timothy]

Matt Price  writes:

> Really, I feel like there should be a parade.

There will be one in the next edition of This Month in Org .

-- 
Timothy

STOP this patch for now.

[stardiviner]

> On Jul 8, 2021, at 4:59 PM, Christian Hopps  wrote:
> 
> It may eventually be incorporated into the very popular emacs-mac port 
> (railwaycat tap in homebrew); however, it will probably not be incorporated 
> into the nextstep/emacs main code. I started looking at doing a version for 
> the mainline code, but it’s hard to get motivated b/c using that version of 
> emacs on OS X is a pretty sub-par experience.

Thanks for your work on this support. I found upstream is less active. Don’t 
know when will be merged.

> 
> I only commented on this b/c I think you might are disabling 
> notifications-notify which work great with my code changes, and using 
> something else if you see Darwin OS, and that will break my native “Just 
> Works” support for notifications, which again may end up on many peoples 
> machines. I would ask that the patch be modified in a way that didn’t break 
> native support if present before it was accepted.
> 
> Also as you can see by the multiple patches you’ve submitted there’s really 
> no good answer for an external notifier, so whatever you pick is probably 
> going to be wrong for someone I guess.

Yes, this troubled my too. Currently no good solution. I will stop this patch 
for now. Wait for upstream emacs-mac port support. Hope it will be arrived in 
at leas half of year.

> 
> If this patch is going to be accepted I would ask that it
> 
> 1) be conditional (disable-able with a variable)
> 2) do the check for the custom installed external notifier and if not present 
> then fallback to using the emacs supplied notifications-notify
> 3) not restrict notifications-notify to gnu/linux only.
> 
> That way people that have already developed solutions for this won’t have 
> them broken.
> 
> Thanks,
> Chris.
> 
>> On Jul 7, 2021, at 8:00 PM, stardiviner > > wrote:
>> 
>> 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 

Re: convert subtree or nested list to table

[tbanelwebmin]

When I run you example I get:

#+RESULTS:
| Category | (unordered (A) (B) (C) (D) (F)) |
| Writing  | (unordered (great) (good) (ok) (lousy) (awful)) |


To get your result I need to modify
   :results table
to
   :results table code

You may try
   :results table raw
Or try your example without any hidden customisation
   emacs -q

This info page may be useful:
[[info:org#Results of Evaluation]]


Le 07/07/2021 à 23:13, Matt Price a écrit :
> 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)) |
> ___
>
>

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

[Christian Hopps]

It may eventually be incorporated into the very popular emacs-mac port 
(railwaycat tap in homebrew); however, it will probably not be incorporated 
into the nextstep/emacs main code. I started looking at doing a version for the 
mainline code, but it’s hard to get motivated b/c using that version of emacs 
on OS X is a pretty sub-par experience.

I only commented on this b/c I think you might are disabling 
notifications-notify which work great with my code changes, and using something 
else if you see Darwin OS, and that will break my native “Just Works” support 
for notifications, which again may end up on many peoples machines. I would ask 
that the patch be modified in a way that didn’t break native support if present 
before it was accepted.

Also as you can see by the multiple patches you’ve submitted there’s really no 
good answer for an external notifier, so whatever you pick is probably going to 
be wrong for someone I guess.

If this patch is going to be accepted I would ask that it

1) be conditional (disable-able with a variable)
2) do the check for the custom installed external notifier and if not present 
then fallback to using the emacs supplied notifications-notify
3) not restrict notifications-notify to gnu/linux only.

That way people that have already developed solutions for this won’t have them 
broken.

Thanks,
Chris.

> On Jul 7, 2021, at 8:00 PM, stardiviner  wrote:
> 
> 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

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,

Mark Barton  writes:

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

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

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Do not throw error when parameter of :tangle is not a string

[Sébastien Miquel]

Hi,

Jacopo De Simoi writes:

  in the current master branch, if the parameter :tangle of a src block is not
a string, tangling fails by throwing  an error when calling `file-name-
directory'  This patch checks if the parameter is a string before calling
`file-name-directory'.

This makes construct such as :tangle (when condition-applies "filename") work
again (as they did a few versions ago…)

Thanks for the patch. It looks good to me (had to run `dos2unix' to apply).

To clarify, it fixes `:tangle (when condition-applies "filename")' when the
condition doesn't apply, such as `(when nil "filename")'.

Regards,

--
Sébastien Miquel

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

[Colin Baxter]

I'm afraid I for one often have empty attach directories which I leave
alone knowing that one day soon - sometimes very soon - they will be used
again. Cannot the user be asked if he wants the directory removed?

Best wishes,

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

[Greg Minshall]

Matt Price  wrote:

> Really, I feel like there should be a parade.

+1

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

[Tim Cross]

Marco Wahl  writes:

>>> 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.
>
> I think it's too much effort to keep a list of attachment directories
> which have been created by Org attachment commands.  Complexity!  (BTW
> org-attach-sync does not create an attachment directory.  It rather
> checks the state of the directory and acts accordingly.)

Agreed.

>
> Please recall that only empty attachment directories would be removed,
> so removal of a directory--and in particular one that existed before its
> interpretation as Org attachment--wouldn't be a big deal AFAICS.
>

Not as confident here. I can imagine workflows and other external
scripts which might expect a specific directory structure that could be
broken if a directory was removed (even when empty). Hence my suggestion
it needs to be something you can turn off.

>> Likely this is something which should be controllable via a custom
>> setting?
>
> To be honest I'd rather not make another customizable thing out of it to
> keep the overall complexity low.
>
> OTOH we could easily introduce e.g. customizable
> org-attach-delete-empty-dirs-on-sync.

Appreciate the problem with far too many customization options, but when
it comes to software 'automatically' doing something, like removal of an
empty directory, especially when it might not have been responsible for
creation of the directory, it is better to provide some way to allow the
user to turn off the behaviour. I would default to having it enabled
though.


-- 
Tim Cross

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

[Jens Neuhalfen]

Hi Nicolas,

first: thank you for all the work, especially for thinking of documentation for 
end users. My biggest struggle with the current org (and emacs) documentation 
is the lack of end-to-end examples. This makes it incredibly difficult to get 
things working. It often is like „this is a big puzzle, some pieces are in 
other boxes and we don’t provide a picture of how the final puzzle will look 
like“. The documentation often makes sense once I get it running, though . But 
this is to late.

This being the motivation, I would greatly appreciate the following:

——— snip ———-
Consider the following minimal viable example where an org file with one bibtex 
file is rendered to pdf and html.

This is the BibTex file
#+begin_example bibtex
….
#+end_example

This is the org file
#+begin_example org
….
#+end_example

and this is the rendered html/Latex 

- picture 1
- screenshot 2

This has been achieved with the following minimal configuration:

#+begin_example elisp 
….
#+end_example

As you can see in line 42 the … etc, etc

If you would like to use two bibtex files you would need to change …

#+begin_example elisp 
….
; change line 14 in the sample for one file like this:
(…)
…
#+end_example

——- snap ——-


That kind of documentation would have made many, many hours of frustrating 
„search in google/github for a solution someone else has found“ and replace it 
with „wow that was actually quite beginner friendly!“. Pictures also make it 
much easier to visualize what is actually achieved.

Cheers
Jens

> On 8. Jul 2021, at 02:18, Nicolas Goaziou  wrote:
> 
> 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: [WDYT] org-attach-sync better remove an empty attachment directory?

[Marco Wahl]

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

I think it's too much effort to keep a list of attachment directories
which have been created by Org attachment commands.  Complexity!  (BTW
org-attach-sync does not create an attachment directory.  It rather
checks the state of the directory and acts accordingly.)

Please recall that only empty attachment directories would be removed,
so removal of a directory--and in particular one that existed before its
interpretation as Org attachment--wouldn't be a big deal AFAICS.

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

To be honest I'd rather not make another customizable thing out of it to
keep the overall complexity low.

OTOH we could easily introduce e.g. customizable
org-attach-delete-empty-dirs-on-sync.

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

[Greg Minshall]

Uwe,

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

ah, well.  :)

i realized you probably wanted the table back.  below it is, with your
explanation of "@3$3".

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

well, takes all kinds.  :)

cheers, Gerg



#+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[X == "Weight:", "Weight2"]),
   0.0) +
(min(10, some[, "DMNI.H"]) * some[X == "Weight:", "ExNDM.I"]) +
(ifelse(some[, "ExNDNM.J"] > 10, some[, "ExNDNM.J"] - 10 *
 some[X == "Weight:", "DMNI.H"], 0)) +
(min(10, some[, "ExNDNM.J"]) *
 some[X == "Weight:", "ExNDNM.J"]) +
(some[X == "Weight:", "Result"] *
 some[, "Result"])

  some
#+end_src

#+RESULTS:
| X   | 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 | |

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

[Joost Kremers]

On Thu, Jul 08 2021, Bruce D'Arcus wrote:
> 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?

One thing to keep in mind here: these are two different sets of functionality
and a tool designed to handle one isn't necessarily right for handling the
other.

Org-cite provides four capabilities: insert, follow, activate and export. And
while they may be very similar conceptually for a user, a provider would need to
handle each of these very differently for citations and in-document references.

And that's the point: while it makes sense for Ebib to provide insert and follow
capabilities for citations, there is really no point in Ebib providing those for
in-document references as well. It doesn't have the infrastructure for it, nor
is Ebib the first (or even second or third) option that comes to mind when you
think about inserting and following in-document references.

I do think it makes sense if such a hypothetical org-new-ref has a very similar
conceptual design to org-cite and a very similar user interface (e.g., the same
keybindings), and perhaps a part of the code can be shared, it should be
possible to register different provides for them.

-- 
Joost Kremers
Life has its moments

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