Inconsistent usage of "overview"

[Carlos Pita]

Hi all,

Here is something I find very confusing. In [1]:

#+STARTUP: overview
#+STARTUP: content
#+STARTUP: showall
#+STARTUP: showlevels
#+STARTUP: showeverything

In org-startup-folded docstring it is said that it takes values equivalent to:

   #+STARTUP: fold  (or ‘overview’, this is equivalent)
   #+STARTUP: nofold(or ‘showall’, this is equivalent)
   #+STARTUP: content
   #+STARTUP: showlevels ( = 2..5)
   #+STARTUP: showeverything

The fact that "overview" is also called "fold" doesn't make what
follows simpler, but so far so good.

Then there is the function org-overview, which:

Switch to overview mode, showing only top-level headlines.

But org-overview shows drawers unfolded while "overview" mode folds
drawers at startup. That is, if you start in "fold" or "overview" mode
(as in #+STARTUP or org-startup-folder) and then cycle visibility all
the way back to "overview" (now as in org-overview) you're not at the
beginning again.

I would say that this is not intentional but an inconsistency in what
"overview" means that should be resolved some way or another. For me
it makes sense that drawers begin folded in an overview and the
docstring of org-overview seems to suggest that. Moreover, while
cycling the rest of the "more expanded" visibility states fold
drawers.

And sometimes properties represent a disproportionate part of the
document when compared to folded top-level headlines. For example, I'm
thinking of brief org-roam notes showing an awful UUID at the top
which is IMO not relevant to an overview.

Best regards,
Carlos

---

[1] https://orgmode.org/manual/Initial-visibility.html

Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el

[stardiviner]

I would like to be the maintainer of org-contacts.el. (I might already
replied this message? Sorry if duplicated.)
I have separated and put org-contacts on GitHub
https://github.com/stardiviner/org-contacts.el.
And I'm in the progress to put it on NonGNU ELPA or MELPA.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Mon, Dec 14, 2020 at 2:06 PM Bastien  wrote:

> Hi stardiviner,
>
> what is the last state of your patch?  Feel free to resend it,
> I will apply it.
>
> Also, do you want to become the maintainer for org-contacts.el?
>
> Remember, elisp files in contrib/ will soon be extracted from
> the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr
>
> Still, it's useful to already know who will be in charge.
>
> Thanks,
>
> --
>  Bastien
>

Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]

[Aaron Jensen]

Here is another that just happened:
https://gist.github.com/aaronjensen/5294a64f243a306b58062113b9306bab

It's scrubbed of all string data, hopefully not over-scrubbed for you.

Aaron

Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]

[Aaron Jensen]

On Mon, Nov 1, 2021 at 8:48 AM Ihor Radchenko  wrote:
>
> Aaron Jensen  writes:
>
> > On Sat, Oct 30, 2021 at 11:16 PM Aaron Jensen  wrote:
> >>
> >> Done, I'll report back.
> >
> > Another one, no trace:
> >
> > Warning (emacs): Emacs reader failed to read data for # > config.org>:org-element--cache. The error was: "Invalid read syntax:
> > \"#\", 1, 4670" Disable showing Disable logging
>
> Thanks! I have seen this one. Now can confirm that it is not just on my
> system. This warning indicates a likely bug in Emacs read/write. I
> disabled this warning on latest main to not irritate users.
>
> Best,
> Ihor

Here is a backtrace. The package it mentions is my own:
https://github.com/aaronjensen/emacs-orgonomic and
https://github.com/Somelauw/evil-org-mode is mentioned too.

Warning (emacs): org-element--cache: Warning(20211101-journal):
Unregistered buffer modifications detected. Resetting.
If this warning appears regularly, please report it to Org mode
mailing list (M-x org-submit-bug-report).
The buffer is: 20211101-journal
 Current command: nil
 Backtrace:
"  backtrace-to-string(nil)
  org-element--cache-sync(#)
  apply(org-element--cache-sync #)
  timer-event-handler([t 0 0 59 nil org-element--cache-sync
(#) idle 99 nil])
"
Backtrace:
  org-element-cache diagnostics(20211101-journal): Nothing to remove.
No elements in cache after 361. Terminating.
  org-element-cache diagnostics(20211101-journal): Found non-robust
change invalidating org-data. Re-parsing: "(org-data (:begin 1
:contents-begin 1 :contents-end 360 :end 360 :robust-begin 3
:robust-end 358 :post-blank 0 :post-affiliated 1 :path \"/path\" :mode
org-data :CATEGORY \"20211101-journal\" :parent nil :cached t
:org-element--cache-sync-key (4 . -1)))"
  org-element-cache diagnostics(20211101-journal): Adding new phase 0 request
  org-element-cache diagnostics(20211101-journal): Submitting new
synchronization request for [360..361]흙-1
  org-element-cache diagnostics(20211101-journal): save-buffer is
about to modify text: warning nil
  org-element-cache diagnostics(20211101-journal): After change
  org-element-cache diagnostics(20211101-journal): save-buffer is
about to modify text: warning nil
  org-element-cache diagnostics(20211101-journal): Nothing to remove.
No elements in cache after 364. Terminating.
  org-element-cache diagnostics(20211101-journal): Found non-robust
change invalidating org-data. Re-parsing: "(org-data (:begin 1
:contents-begin 1 :contents-end 360 :end 361 :robust-begin 3
:robust-end 358 :post-blank 1 :post-affiliated 1 :path \"/path\" :mode
org-data :CATEGORY \"20211101-journal\" :parent nil :cached t
:org-element--cache-sync-key (4 . -1)))"
  org-element-cache diagnostics(20211101-journal): Adding new phase 0 request
  org-element-cache diagnostics(20211101-journal): Submitting new
synchronization request for [361..364]흙-3
  org-element-cache diagnostics(20211101-journal): evil-org-delete is
about to modify text: warning 2
  org-element-cache diagnostics(20211101-journal): After change
  org-element-cache diagnostics(20211101-journal): evil-org-delete is
about to modify text: warning 2
  org-element-cache diagnostics(20211101-journal): Nothing to remove.
No elements in cache after 365. Terminating.
  org-element-cache diagnostics(20211101-journal): Found non-robust
change invalidating org-data. Re-parsing: "(org-data (:begin 1
:contents-begin 1 :contents-end 364 :end 364 :robust-begin 3
:robust-end 362 :post-blank 0 :post-affiliated 1 :path \"/path\" :mode
org-data :CATEGORY \"20211101-journal\" :parent nil :cached t
:org-element--cache-sync-key (4 . -1)))"
  org-element-cache diagnostics(20211101-journal): Adding new phase 0 request
  org-element-cache diagnostics(20211101-journal): Submitting new
synchronization request for [364..365]흙-1
  org-element-cache diagnostics(20211101-journal):
orgonomic-delete-backward-char is about to modify text: warning 2
  org-element-cache diagnostics(20211101-journal): After change
  org-element-cache diagnostics(20211101-journal):
orgonomic-delete-backward-char is about to modify text: warning 2
  org-element-cache diagnostics(20211101-journal): Nothing to remove.
No elements in cache after 366. Terminating.
  org-element-cache diagnostics(20211101-journal): Found non-robust
change invalidating org-data. Re-parsing: "(org-data (:begin 1
:contents-begin 1 :contents-end 365 :end 365 :robust-begin 3
:robust-end 363 :post-blank 0 :post-affiliated 1 :path \"/path\" :mode
org-data :CATEGORY \"20211101-journal\" :parent nil :cached t
:org-element--cache-sync-key (4 . -1)))"
  org-element-cache diagnostics(20211101-journal): Adding new phase 0 request
  org-element-cache diagnostics(20211101-journal): Submitting new
synchronization request for [365..366]흙-1
  org-element-cache diagnostics(20211101-journal):
orgonomic-delete-backward-char is about to modify text: warning 2
  org-element-cache diagnostics(20211101-journal): After change
  org-element-cache diagnostics(20211101-journal):

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Tim Cross]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>> Ihor, your fix affects linux as well. .cache directory may be missed in 
>> fresh accounts. E.g. I just have created a new test container (my old 
>> one has emacs-25):
>
> After second thought, I am not sure anymore if using XDG is a good idea.
> Emacs itself only recently started supporting XDG and the support is
> somewhat limited. Similar to the described case with non-existing .cache
> directory, Emacs ignores non-existing .config/emacs folder for init.el.
> Emacs never creates .config directory.
>
> So, I can see several options for Org:
> 1. Just move to back usual usage of user-emacs-directory and store the
>cache there
> 2. Use the same approach with Emacs: if $XDG_CACHE_DIR/org-persist
>exists and user-emacs-directory/org-persist does not, use the XDG
>dir. Otherwise fall back to user-emacs-directory
> 3. Same as 2, but only require existing $XDG_CACHE_DIR and create
>$XDG_CACHE_DIR/org-persist dir if possible.
> 4. Same as 3, but create $XDG_CACHE_DIR if possible. It is similar to
>other XDG-complient software (at least, that's what I saw in
>qutebrowser code).
>

I think the key is to be consistent with user expectations. If the
user's init.el is under XDG layout, then use that, otherwise use
user-emacs-dir. This is slightly different to your No. 2, as I suspect
in the first run of org, it could be possible that init.el is under XDG
layout, but there is no org-persist yet.

Most important requirement would be that the location is a custom
variable, allowing easy customisation for those who want to set it
explicitly.

Re: reference a remote named block in #+CALL: line

[Michael Welle]

Hello,

Matt Price  writes:

> I am getting used to calling library-of-babel functions with local data
> structures as input variables, e.g. in this line:
>
> #+CALL: list2table(data=common-issues-list, order="rows") :results  table
>  raw
[...]
> In this particular case, I'd like to maintain a single data structure and
> use it in a bunch of places (it's a document I re-use in several courses,
> all of which are published online with different metadata stored in
> headings). Is there a syntax for referring to #+NAME'd elements in remote
> files?
that's what I use with tables (but that should not matter):

#+CALL: list2table(data=data.org:common-issues-list, order="rows") :results  
table raw

Regards
hmw

Re: reference a remote named block in #+CALL: line

[Berry, Charles]

Matt,

> On Nov 2, 2021, at 3:19 AM, Matt Price  wrote:
> 
> I am getting used to calling library-of-babel functions with local data 
> structures as input variables, e.g. in this line:
> 
> #+CALL: list2table(data=common-issues-list, order="rows") :results  table  
> raw 
> 
> where `common-issues-list` is a named org-mode list in the current file, e.g. 
> 
> #+NAME: common-issues-list
> - some
> - things
> - here
> 
> In this particular case, I'd like to maintain a single data structure and use 
> it in a bunch of places (it's a document I re-use in several courses, all of 
> which are published online with different metadata stored in headings). Is 
> there a syntax for referring to #+NAME'd elements in remote files?
> 
> Sorry if I'm missing something that is explained in the docs -- I am not 
> finding this in what I think of as the obvious places.  
> 

AFAIK, there is nothing like this.

However, it looks like it would be easy to modify `org-babel-lob-ingest' by 
adding another argument giving the name (or a list of names) of src blocks that 
you want added to `org-babel-library-of-babel' by replacing the `when 
source-name' with something like `when (member source-name only-these-names)' 
so only src blocks you want to invoke are ingested.

HTH,

Chuck

Re: [PATCH] oc-basic: support biblatex date field

[Bruce D'Arcus]

On Tue, Nov 2, 2021 at 1:44 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > This is a tiny change that just checks for a 'date' field if 'year' is
> > nil, and if present, grabs the first four characters.
>
> The date field may also be nil, leading to an error.

Can you please fix that, if the patchis otherwise fine?

> Is there a guarantee that the date field starts with the year?

Not 100% guarantee, but should be close.

The biblatex manual (section 2.3.8 Date and Time Specifications), says
the following:

"Date fields such as the default data model dates date, origdate,
eventdate, and urldate adhere to iso8601-2 Extended Format
specification level 1."

This is an extension to standard 8601 dates, previously known as EDTF
(extended date-time format).

So for the vast majority of cases, yes; the value would be standard 8601 dates.

The exceptions should be very rare open-ended ranged dates; from table 3.

../1997
/1997

I do not, however, have a good knowledge of what people do in the
wild. It just seems like such a critical data field should be
supported.

Bruce

PS - FSF confirmed my copyright assignment today.

Re: [PATCH] oc-basic: support biblatex date field

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> This is a tiny change that just checks for a 'date' field if 'year' is
> nil, and if present, grabs the first four characters.

The date field may also be nil, leading to an error.

Is there a guarantee that the date field starts with the year?

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] oc-csl: Fix footnote status reporting for wrapped citations

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

> the attached simple patch fixes a problem in oc-csl.el which led to
> missing footnote number information for citations that were
> automatically footnote-wrapped based on the used CSL style.

Applied with a small change. Thank you.

> +  (setq footnote (org-element-lineage citation
> +  '(footnote-definition 
> footnote-reference

I removed `footnote-definition', which cannot happen after a call to
`org-cite-wrap-citation'.

Regards,
-- 
Nicolas Goaziou

Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Mark Barton]

It looks like follow-mode-prefix is a variable you can customize. It defaults 
to "C-c .” which is why the org-time-stamp does not run with "C-c .”

To see the follow-mode-map use "M-x describe-keymap follow-mode-map”



> On Nov 2, 2021, at 8:23 AM, Michael Maurer  wrote:
> 
> On Tue, 2 Nov 2021 at 09:41, Colin Baxter   wrote:
>> 
>>> Michael Maurer  writes:
>> 
>>> Subject line says it all, I upgraded to 9.5 two days ago and
>>> everything seemed to work, but today I fire up the PC and C-c . no
>>> longer is bound to anything. I guess I could custom-bind it in my
>>> config, but I'm more interested in why it's happening. The last
>>> package I installed after the upgrade was undo-fu and
>>> undo-fu-sessions, but I dont' think they are involved.
>> 
>> They could be. I don't have those packages and C-c . works for me and I
>> am running the latest git pull from org-mode. You might also have
>> multiple org files present.
>> 
>> Best wishes.
> 
> I figured it out. It's follow-mode. As soon as you enable it in a
> buffer, C-c . stops working. I'm not sure if this incompatibility got
> introduced with 9.5, since it's been years since I last used
> follow-mode.
> 

[PATCH] oc-csl: Fix footnote status reporting for wrapped citations

[András Simonyi]

Dear All,

the attached simple patch fixes a problem in oc-csl.el which led to
missing footnote number information for citations that were
automatically footnote-wrapped based on the used CSL style.

best wishes,
András
From 1423e0f600d8e4e29f275faa9c9117db9b081b19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Tue, 2 Nov 2021 16:44:37 +0100
Subject: [PATCH] oc-csl: Fix footnote status reporting for wrapped citations

* lisp/oc-csl.el (org-cite-csl--create-structure): Update footnote information
when citation is wrapped in a footnote.
---
 lisp/oc-csl.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 42886dc44..f59b14a88 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -506,7 +506,9 @@ INFO is the export state, as a property list."
 ;; a footnote, but isn't yet.
 (when (and (not footnote) (org-cite-csl--note-style-p info))
   (org-cite-adjust-note citation info)
-  (org-cite-wrap-citation citation info))
+  (org-cite-wrap-citation citation info)
+  (setq footnote (org-element-lineage citation
+  '(footnote-definition footnote-reference
 ;; Return structure.
 (apply #'citeproc-citation-create
`(:note-index
-- 
2.25.1

Re: Citations: position="first" match not properly evaluated

[András Simonyi]

Dear All,
I think I found the source of this problem in oc-csl.el -- I'll post a
patch shortly.
best wishes,
András

Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Michael Maurer]

On Tue, 2 Nov 2021 at 09:41, Colin Baxter   wrote:
>
> > Michael Maurer  writes:
>
> > Subject line says it all, I upgraded to 9.5 two days ago and
> > everything seemed to work, but today I fire up the PC and C-c . no
> > longer is bound to anything. I guess I could custom-bind it in my
> > config, but I'm more interested in why it's happening. The last
> > package I installed after the upgrade was undo-fu and
> > undo-fu-sessions, but I dont' think they are involved.
>
> They could be. I don't have those packages and C-c . works for me and I
> am running the latest git pull from org-mode. You might also have
> multiple org files present.
>
> Best wishes.

I figured it out. It's follow-mode. As soon as you enable it in a
buffer, C-c . stops working. I'm not sure if this incompatibility got
introduced with 9.5, since it's been years since I last used
follow-mode.

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

[Nicolas Goaziou]

Hello,

Vinicius Vinicius  writes:

> It seems the same should apply for keyword command (from doc: "The ‘keyword’ 
> macro collects all values from NAME keywords throughout the buffer, separated 
> with white space."). Hope the attached
> patch can fix it.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: [BUG] org-cite-insert ignores JSON entries with editors only [9.5 (9.5-g0a86ad @ /home/rasmus/.emacs.d/elpa/org-9.5/)]

[Nicolas Goaziou]

Hello,

autofrettage  writes:

> I recently used oc-basic and oc-csl but ran into a slight problem when I 
> tried to cite
>
> "97 Things Every Programmer Should Know — Collective Wisdom from the 
> Experts", 1st ed.; Henney, K., Ed.; O’Reilly Media, Inc., 2010.
>
> ...with the command org-cite-insert. Typing "Henney" produced no suggestions.
>
> After editing the JSON file from Zotero manually, making Henney an author 
> instead of an editor, everything worked as expected.
>
> As you may guess, the book is a collection of expert tips from many different 
> programmers, and Kevlin Henney is "just" the editor.
>
> The same happened for some other sources having editors, but no
> authors.

The default "insert" processor, i.e., "oc-basic" is very limited. You
may want to plug more powerful insert processors. See, e.g., "citar"
() project.

Regards,
-- 
Nicolas Goaziou

Re: add automatically a counter to a header/TODO???

[Eric S Fraga]

On Monday,  1 Nov 2021 at 20:53, Uwe Brauer wrote:
>(format "%s" (- 1 (string-to-number

Shouldn't this be the other way around, i.e.
(- (string-to-number ...) 1)
?

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-186-gb135b8
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [BUG] Org V 9.5 error when ~/.cache doesn't exist

[Ihor Radchenko]

Max Nikulin  writes:

> Ihor, your fix affects linux as well. .cache directory may be missed in 
> fresh accounts. E.g. I just have created a new test container (my old 
> one has emacs-25):

After second thought, I am not sure anymore if using XDG is a good idea.
Emacs itself only recently started supporting XDG and the support is
somewhat limited. Similar to the described case with non-existing .cache
directory, Emacs ignores non-existing .config/emacs folder for init.el.
Emacs never creates .config directory.

So, I can see several options for Org:
1. Just move to back usual usage of user-emacs-directory and store the
   cache there
2. Use the same approach with Emacs: if $XDG_CACHE_DIR/org-persist
   exists and user-emacs-directory/org-persist does not, use the XDG
   dir. Otherwise fall back to user-emacs-directory
3. Same as 2, but only require existing $XDG_CACHE_DIR and create
   $XDG_CACHE_DIR/org-persist dir if possible.
4. Same as 3, but create $XDG_CACHE_DIR if possible. It is similar to
   other XDG-complient software (at least, that's what I saw in
   qutebrowser code).

WDYT?

Best,
Ihor

reference a remote named block in #+CALL: line

[Matt Price]

I am getting used to calling library-of-babel functions with local data
structures as input variables, e.g. in this line:

#+CALL: list2table(data=common-issues-list, order="rows") :results  table
 raw

where `common-issues-list` is a named org-mode list in the current file,
e.g.

#+NAME: common-issues-list
- some
- things
- here

In this particular case, I'd like to maintain a single data structure and
use it in a bunch of places (it's a document I re-use in several courses,
all of which are published online with different metadata stored in
headings). Is there a syntax for referring to #+NAME'd elements in remote
files?

Sorry if I'm missing something that is explained in the docs -- I am not
finding this in what I think of as the obvious places.

thanks as always,

Mat

Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Colin Baxter ]

> Michael Maurer  writes:

> Subject line says it all, I upgraded to 9.5 two days ago and
> everything seemed to work, but today I fire up the PC and C-c . no
> longer is bound to anything. I guess I could custom-bind it in my
> config, but I'm more interested in why it's happening. The last
> package I installed after the upgrade was undo-fu and
> undo-fu-sessions, but I dont' think they are involved.

They could be. I don't have those packages and C-c . works for me and I
am running the latest git pull from org-mode. You might also have
multiple org files present.

Best wishes.

Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Michael Maurer]

On Tue, 2 Nov 2021 at 09:36, Michael Maurer  wrote:
>
> On Tue, 2 Nov 2021 at 09:18, Michael Maurer  wrote:
> >
> > Subject line says it all, I upgraded to 9.5 two days ago and
> > everything seemed to work, but today I fire up the PC and C-c . no
> > longer is bound to anything. I guess I could custom-bind it in my
> > config, but I'm more interested in why it's happening. The last
> > package I installed after the upgrade was undo-fu and
> > undo-fu-sessions, but I dont' think they are involved.
>
> Update: After exiting and restarting Emacs, it works again. (?)

Update 2: No, it only seems to affect certain org-files, trying to
figure out why. Sorry for the spam!

Re: C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Michael Maurer]

On Tue, 2 Nov 2021 at 09:18, Michael Maurer  wrote:
>
> Subject line says it all, I upgraded to 9.5 two days ago and
> everything seemed to work, but today I fire up the PC and C-c . no
> longer is bound to anything. I guess I could custom-bind it in my
> config, but I'm more interested in why it's happening. The last
> package I installed after the upgrade was undo-fu and
> undo-fu-sessions, but I dont' think they are involved.

Update: After exiting and restarting Emacs, it works again. (?)

C-c . no longer inserts org-time-stamp (after upgrade to 9.5)

[Michael Maurer]

Subject line says it all, I upgraded to 9.5 two days ago and
everything seemed to work, but today I fire up the PC and C-c . no
longer is bound to anything. I guess I could custom-bind it in my
config, but I'm more interested in why it's happening. The last
package I installed after the upgrade was undo-fu and
undo-fu-sessions, but I dont' think they are involved.