Re: Syncing orgcard.tex with upstream Emacs (was: bug#64578: orgcard.tex fixes to allow PDF rendering to be used as a triptych.)

[Kyle Meyer]

Ihor Radchenko writes:

> I see now. I guess I did not really have a full understanding of the
> purpose of emacs-sync. So, it might be helpful to add a similar
> explanation to worg/org-maintenance.org.

Okay, I'll plan to do that.

>> I don't see what problem it solves.  It's moving the divergence to a
>> different file (that would still be tracked in emacs-sync), and it adds
>> one more Org-specific wrinkle to the Emacs tree.  (Also, the orgcard
>> source would still be different given the upstream hunk in the diff I
>> posted in my last message.)
>
> My idea was not to sync that another extra file at all and leave it in
> Emacs repo only.

I see.  Not that it matters given what you say below, but I would
probably lean toward keeping track of such a file in emacs-sync.

> But the same will not work for xml and other diverging
> files. I now don't see any reason to change the existing state of affairs.

All right, thanks for your input.  I'll try to improve
worg/org-maintenance.org as discussed.

Re: Syncing orgcard.tex with upstream Emacs (was: bug#64578: orgcard.tex fixes to allow PDF rendering to be used as a triptych.)

[Kyle Meyer]

Ihor Radchenko writes:

> I think that a reference to
> https://git.kyleam.com/orgmode-backport-notes/tree/orgmode-backports.org#n2
> might be helpful.

Okay, I'll make a note to add one.

> Maybe we should even have that file in the main repo as a part of
> emacs-sync branch?

I prefer not to.  I intended that branch to track the state of Org files
that are synced, not to store auxiliary logs.

> I can see the point. Although, I feel like accumulating such divergence
> may backfire after some time.

How do you see this particular spot backfiring?  If Emacs changes the
Emacs-specific text (as they did once in 2016), I port that to the
emacs-sync branch.  Or if Org changes neighboring text, I resolve the
conflict on merge into emacs-sync (very likely just taking both sides).
The resolution is recorded for anyone to look back on.

The emacs-sync branch provides a transparent way to keep track of the
limited set of Emacs-specific modifications needed for the sync.  We're
not talking about an ever-growing set of changes.

> May we possibly resolve the conflict properly using something like the
> attached patch?  Then, we can use the same orgcard source but have
> orgcardemacsnotice.tex empty in Org repository.

I don't see what problem it solves.  It's moving the divergence to a
different file (that would still be tracked in emacs-sync), and it adds
one more Org-specific wrinkle to the Emacs tree.  (Also, the orgcard
source would still be different given the upstream hunk in the diff I
posted in my last message.)

> Are there other similar conflicts in emacs-sync branch?

The emacs-sync branch has other Emacs-specific modifications, yes.
Again, keeping track of those is the reason it exists.

  $ git diff --stat bugfix...emacs-sync
   .gitignore   |  1 -
   doc/{doc-setup.org => org-setup.org} |  2 +-
   doc/{org-manual.org => org.org}  |  4 ++--
   doc/orgcard.tex  |  7 ++-
   etc/schema/schemas.xml   | 57 
+
   lisp/org-version.el  | 24 
   6 files changed, 90 insertions(+), 5 deletions(-)

Re: Syncing orgcard.tex with upstream Emacs (was: bug#64578: orgcard.tex fixes to allow PDF rendering to be used as a triptych.)

[Kyle Meyer]

Ihor Radchenko writes:

> Kyle Meyer  writes:
>
>> Here is the difference between the two cards, as of the last sync:
>>
>>   -\input org-version.tex
>>   +\def\orgversionnumber{9.6.11}
>>   +\def\versionyear{2023}  % latest update
>>   +\input emacsver.tex
>> ...
>>   +\centerline{For more Emacs documentation, and the \TeX{} source for this 
>> card, see}
>>   +\centerline{the Emacs distribution, or {\tt 
>> https://www.gnu.org/software/emacs}}
>>   +
>
> Aside: It appears to be only partially documented in
> https://orgmode.org/worg/org-maintenance.html#emacs-sync. In particular,
> the last two lines.

I'm happy to clarify or add to those docs.  I didn't write them, but I
did go through them somewhat recently to better align them with the
actual porting/syncing process.

With respect to the emacs-sync branch, that page currently says

  Typically, Org can be synchronized by copying over files from the
  emacs-sync branch of the Org repository to the master branch of Emacs
  repository. The emacs-sync branch has a few extra changes compared
  with the bugfix branch

Would you like me to add more details about why the branch exists?  How
it's managed?  Something else?

> May we just add
>
>>   +\centerline{For more Emacs documentation, and the \TeX{} source for this 
>> card, see}
>>   +\centerline{the Emacs distribution, or {\tt 
>> https://www.gnu.org/software/emacs}}
>
> to Org repo?

These lines (or rather what became these lines) were added in Emacs's
4af5981dc75 (Add a comment in generated refcards about the source,
2016-11-17).  I decided to port that commit to emacs-sync rather than a
primary Org branch because I felt it only applied to the Org card
distributed as part of the Emacs tree.  From my notes [*]:

  I'm skipping this because it isn't true when the card is from the Org
  mode repo.

However, if you prefer to include those lines in Org's copy, that's fine
by me.


[*] 
https://git.kyleam.com/orgmode-backport-notes/tree/orgmode-backports.org?id=35eaf5a21dc776c9f7a880d0a4bf9ffc48213985#n3464

Re: Missing changes

[Kyle Meyer]

Po Lu writes:

> These changes made to lisp/org within the Emacs repository are absent
> from orgmode.git:
>
> * | 73b24a41412..: Po Lu 2023-08-23 Make org-mouse compatible with touch 
> screen event emulation
> * | 4f714dc0813..: Po Lu 2023-08-20 Support desktop notifications on Android
> * | 5856ea5e4e8..: Po Lu 2023-08-17 Introduce support for Desktop 
> Notifications on Haiku
>
> Would anyone care to see to it that they are transferred into the Org
> repository?

Those commits are on Emacs's master branch.  We're up to date with the
emacs-29 branch, but I've yet to port any of the Emacs's master-specific
Org changes to Org's main branch.  I started working on it last weekend,
so it should happen soon-ish.  In any case, all the currently unported
master-specific changes would of course be ported to Org's main before
we start syncing that to Emacs's master.

You can find all of these commits listed at

  https://git.kyleam.com/orgmode-backport-notes/tree/orgmode-backports.org

It's not in your list above, but there's also your 9082b4e6ee2 (Make
binaries distributed with Emacs work on Android, 2023-01-24).  That, by
the way, will need to be adjusted to stay compatible with previous Emacs
versions that don't have a ctags-program-name variable defined.

Re: Minimal list of packages for `guix shell` for documentation compilation?

[Kyle Meyer]

Kyle Meyer writes:

> Ah, sorry, I should have tested that with --pure.  Indeed you'll need to
> pull in other packages if they're not already on your system.  [...]

Here's the minimum set of packages I needed with --pure:

 $ guix shell --pure \
   coreutils diffutils emacs-minimal glibc git grep make sed tar texinfo 
texlive \
   -- make doc

(Note: texlive is large, so that will take some time if you don't
already have it in your store.)

Re: Minimal list of packages for `guix shell` for documentation compilation?

[Kyle Meyer]

Kyle Meyer writes:

> Running this from the top of the Org repo works for me (Guix
> 270db2a56bc5):
>
>   $ guix shell emacs -- make doc

Ah, sorry, I should have tested that with --pure.  Indeed you'll need to
pull in other packages if they're not already on your system.  Adding
'-D emacs' to pull in emacs dev inputs may you a good way there, but
you'll probably at least need to add texlive on top.  (Sorry, I can't
test at the moment.)

Re: Minimal list of packages for `guix shell` for documentation compilation?

[Kyle Meyer]

Yuval Langer writes:

> I would like to run `make doc` under `guix shell` to test my
> documentation patches.
>
> Does anyone know the minimal list of packages and proper `guix shell`
> incantation for that?

Running this from the top of the Org repo works for me (Guix
270db2a56bc5):

  $ guix shell emacs -- make doc

Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Kyle Meyer writes:

> I'm not sure what's intended here.  There are spots in public-inbox that
> favor a date from Received headers.  I've sent a message to
> public-inbox's list:
>
>   https://public-inbox.org/meta/87edr5gx63@kyleam.com

Eric replied with a patch that resolved the issue.  I've installed it.

Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Oy, sorry about mangling the subject :x

I started to change it to cc  but then decided to
start send a separate message, but forgot about the in-between subject
change.

future value for Date header can pin thread to top of $inbox/ list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/bui

[Kyle Meyer]

Ihor Radchenko writes:

> We currently have a message in future on top of
> https://list.orgmode.org/

Hmm, that's unfortunate.

> The message is
> https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw, and
> it does not contain the future dates in headers. Just in the body.

Look again at its date header:

  $ curl -fSsL 
https://list.orgmode.org/ZT2vNKsf3Lp5xit3@protected.localdomain/raw | \
grep Date:
  Date: Sun, 29 Oct 2023 04:02:44 +0300

> Are we observing public inbox bug?

I'm not sure what's intended here.  There are spots in public-inbox that
favor a date from Received headers.  I've sent a message to
public-inbox's list:

  https://public-inbox.org/meta/87edr5gx63@kyleam.com

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Kyle Meyer]

Ihor Radchenko writes:

> I have recently been contacted by the current compat.el maintainer
> asking if we are willing to adapt compat.el in Org.

I'm in favor of Org using Compat.  And grepping around emacs.git, there
are already two bundled packages (erc and python) with

  (require 'compat nil 'noerror)

so I don't expect there would be objections/questions from the Emacs
side.

list.orgmode.org: planned maintenance on 2023-01-15

[Kyle Meyer]

https://list.orgmode.org will be intermittently offline on Sunday
January 15 during a 19:00-20:00 UTC maintenance window.

Re: 2a529ee57 org-element: Autoload org-element-use-cache

[Kyle Meyer]

Ihor Radchenko writes:

> You wrote in the commit message that autoload.el is deprecated in Emacs
> 29. Do we need to do anything about it in Org make system?

Yes, though I don't consider it urgent given the deprecation hasn't even
made it into a release.  I was planning on doing something like below
(only lightly tested at this point).  And then way down the road we can
drop the compatibility kludge.


diff --git a/mk/org-fixup.el b/mk/org-fixup.el
index 5989875a8..60c39c684 100644
--- a/mk/org-fixup.el
+++ b/mk/org-fixup.el
@@ -24,7 +24,6 @@
 ;;
 ;;; Commentary:
 
-(require 'autoload)
 (require 'org-compat "org-compat.el")
 
 (defun org-make-manual ()
@@ -86,18 +85,22 @@ (defun org-make-org-loaddefs ()
 be used by foreign build systems or installers to produce this
 file in the installation directory of Org mode.  Org will not
 work correctly if this file is not up-to-date."
-  (with-temp-buffer
-(set-visited-file-name "org-loaddefs.el")
-(insert ";;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; 
Code:\n")
-(let ((files (directory-files default-directory
- nil 
"^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?\\.el$")))
-  (mapc (lambda (f) (generate-file-autoloads f)) files))
-(insert "\f\n(provide 'org-loaddefs)\n")
-(insert "\f\n;; Local Variables:\n;; version-control: never\n")
-(insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
-(insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
-(let ((inhibit-read-only t))
-  (save-buffer
+  (let ((outfile "org-loaddefs.el"))
+(if (fboundp 'loaddefs-generate); Emacs >= 29
+(loaddefs-generate default-directory (expand-file-name outfile))
+  (require 'autoload)
+  (with-temp-buffer
+(set-visited-file-name outfile)
+(insert ";;; org-loaddefs.el --- autogenerated file, do not 
edit\n;;\n;;; Code:\n")
+(let ((files (directory-files default-directory
+  nil 
"^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?\\.el$")))
+  (mapc (lambda (f) (generate-file-autoloads f)) files))
+(insert "\f\n(provide 'org-loaddefs)\n")
+(insert "\f\n;; Local Variables:\n;; version-control: never\n")
+(insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
+(insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
+(let ((inhibit-read-only t))
+  (save-buffer))
 
 (defun org-make-autoloads ( compile force)
   "Make the files org-loaddefs.el and org-version.el in the install directory.

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Kyle Meyer]

Ihor Radchenko writes:

> I am also wondering if we should include this into bugfix.
> This is a new feature, but it appears to be important enough to be
> merged into built-in Org.
> Bastien, Kyle, any thoughts?

Sounds reasonable to me.

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Kyle Meyer]

Tom Gillespie writes:

[...]
>> :package-version instead of :version?
>
> I think because org is part of emacs core we use the emacs version?

Please use :package-version and let the mapping be handled by
customize-package-emacs-version-alist.

> I see "24.1" included with other org defcustoms.

There has a been a good amount of clean up to remove :version and use
:package-version, but, yes, there are still :version instances.  Things
look good for the last Org release, though:

  $ git grep '29\.1'
  lisp/org.el:   ("9.6" . "29.1")))

Re: [BUG] Org 9.6 Inactive timestamp search no longer works as expected.

[Kyle Meyer]

On 12/03/22 13:44:33 -0500, Carlo Tambuatco wrote:
> Simple inactive timestamp search for recent completed tasks used to return as 
> expected. ie:
>
> +TIMESTAMP_IA>=“”+TIMESTAMP_IA<“” 
>
> would return all tasks that I completed today. (Had an inactive timestamp 
> greater than or equal 
> to 12:00 am of the current day, but less than tomorrow)
> [...]

Thanks for reporting.  I had noticed one of my "" queries had
stopped working but hadn't yet got around to bisecting.  Doing so now,
this looks like a regression from e022a0cea (org-make-tags-matcher: Do
not treat PROPERTY="[X]" as timestamp match, 2022-10-25).

Ihor, I haven't reviewed the linked discussion in that commit, but with
its change (shown below), the regex now longer matches things like
"" and "".

diff --git a/lisp/org.el b/lisp/org.el
index e93a81210..01e0279c8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11337,7 +11337,7 @@ (defun org-make-tags-matcher (match  
only-local-tags)
 (pv (match-string 7 term))
 (regexp (eq (string-to-char pv) ?{))
 (strp (eq (string-to-char pv) ?\"))
-(timep (string-match-p "^\"[[<].*[]>]\"$" pv))
+(timep (string-match-p "^\"[[<][0-9]+.*[]>]\"$" 
pv))
 (po (org-op-to-function (match-string 6 term)
 (if timep 'time strp
(setq pv (if (or regexp strp) (substring pv 1 -1) pv))

Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Kyle Meyer]

Bastien writes:

> Kyle Meyer  writes:
[...]

>> Every spot that calls org-assert-version is preceded by a line that
>> requires org-macs, so isn't this error likely due to a mixed
>> installation/load-path issue where the wrong/older org-macs is taking
>> precedence?
>
> Yes: I thought `org-assert-version' job was to help catching mixed
> installations, so my reasoning was that, even when an old org-macs
> version has been loaded, autoloading `org-assert-version' would help
> report about mixed installation.

I see.  So your goal isn't to resolve any errors due to mixed
installation but instead to get the more informative error message from
org-assert-version?

I don't think autoloading will help because it will look in the
org-macs file at the front of the load-path, and, in the bad case, that
does not have the org-assert-version definition.

Here's a minimal example:

--8<---cut here---start->8---
#!/bin/sh

set -eu

tdir=$(mktemp -d "${TMPDIR:-/tmp}"/autoload-shadow-test-XXX)
cd "$tdir"

mkdir a
cat<<'EOF' >a/foo.el
(defun foo-do ()
  (message "foo"))

(provide 'foo)
EOF

mkdir b
echo "(provide 'foo)" >b/foo.el

cat<<'EOF' >test.el
(add-to-list 'load-path
 (concat default-directory (file-name-as-directory "a")))
(add-to-list 'load-path
 (concat default-directory (file-name-as-directory "b")))

(autoload 'foo-do "foo")
(foo-do)
EOF

emacs -Q --batch --load=test.el
--8<---cut here---end--->8---

If I run that, I see:

  Debugger entered--Lisp error: (error "Autoloading file 
/tmp/autoload-shadow-test-gmlO35u...")
(foo-do)
load-with-code-conversion("/tmp/autoload-shadow-test-gmlO35u/test.el" 
"/tmp/autoload-shadow-test-gmlO35u/test.el" nil t)
command-line-1(("--load=test.el"))
command-line()
normal-top-level()

And commenting out the add-to-list call for b confirms that it works
without the shadowing.

> That said, do you have any idea how to fix the bug people encounter
> when installing Org from ELPA and being bitten by "invalid-function
> org-assert-version"?

Sorry, I don't.  Given a mixed installation where the org-macs at the
front of load-path does _not_ have org-assert-version, I don't see a way
to catch that.  Not helpful at the moment, but I suppose the situation
improves with time as Org versions that do not have org-assert-version
become less abundant.

Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Kyle Meyer]

Bastien writes:

> Some users reported an (invalid-function org-assert-version) error
> when installing Org from ELPA:
>
> https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
> https://www.reddit.com/r/emacs/comments/z7qulo/comment/iyd9vam/?context=3
>
> This patch autoloads `org-assert-version'.

I don't understand the rationale behind this.  Every spot that calls
org-assert-version is preceded by a line that requires org-macs, so
isn't this error likely due to a mixed installation/load-path issue
where the wrong/older org-macs is taking precedence?

> It also removes the ;; generated-autoload-file: "org-loaddefs.el"
> footer in all files and let Make create org-autoloads.el instead.

I'm worried with how this will play with the Org bundled with Emacs.
The autoloads that are now written to lisp/org/org-loaddefs.el will
instead pollute the top-level lisp/loaddefs.el.

When I tested this out in the Emacs repo, running `make` shows many
lines of

WARNING: No org-autoloads.el file could be found from where org.el
is loaded.

and

You need to run "make" or "make autoloads" from Org lisp directory

during the build.  And loading/using Org shows the same.

> Before the patch, installing from ELPA creates both org-loaddefs.el
> and org-autoloads.el, which is confusing.

Hmm, isn't this in line with the lisp/org-loaddefs.el and
lisp/loaddefs.el split that happens for the Emacs repo?

A similar split is used other packages in the Emacs repo as well:

$ find lisp | grep '\-loaddefs.el' | head
lisp/ps-print-loaddefs.elc
lisp/org/org-loaddefs.el
lisp/org/org-loaddefs.elc
lisp/net/tramp-loaddefs.el
lisp/net/tramp-loaddefs.elc
lisp/calc/calc-loaddefs.el
lisp/calc/calc-loaddefs.elc
lisp/textmodes/reftex-loaddefs.el
lisp/textmodes/reftex-loaddefs.elc
lisp/textmodes/texinfo-loaddefs.elc

$ find lisp | grep -c '\-loaddefs.el'
29
$ find lisp | grep -c '\-autoloads.el'
0

And with the port of Emacs's 2682ea1b3 (Org commit 19c3969e7,
2022-10-04), there's also one spot that uses ;;;###org-autoload, which
tells loaddefs-gen.el to direct the autoload to org-loaddefs.el.

> Unless anyone objects, I'll install this patch in the bugfix branch
> tomorrow and release 9.6.1.

I think as is the patch would cause issues, and more generally I'm not
convinced we should be moving away from having an org-loaddefs.el file.
I'm also concerned about this sort of tree-wide change in a patch
release that will be synced to the emacs-29 branch.

Thanks for posting this for discussion, and please let me know if I'm
mistaken about the interaction with the Emacs repo.

Re: Problems getting org-macs.el macros to be loaded

[Kyle Meyer]

Bram Adams writes:

> Hi,
>
> I just built the latest Emacs 29 version from the upstream release 
> branch, which comes with org 9.6-3-ga4d38e (no other org version installed).
>
> Overall, it seems like org-macs.el is not loaded properly, since I get 
> issues with invalid function errors for "org-assert-version" and 
> "org-current-text-indentation", even though those are actually macros. 
> The "org-assert-version" issue caused org to misbehave entirely, [...]

Thanks for reporting.  I haven't been able to trigger any issues loading
and using Org from the emacs-29 branch.  (This is with ./src/emacs -Q
after a clean build on Debian stable configured with native
compilation.)

It sounds like you're confident that are no other Org versions on your
load-path, but, just in case, did you check list-load-path-shadows for
anything suspicious?

Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Ihor Radchenko writes:

> I do recall Nicolas repeatedly voicing against usage of subr-x staff:
>
> https://orgmode.org/list/87wo4en8qk@nicolasgoaziou.fr
   2. we don't use "subr-x.el" in the code base. In particular, it 
 would be
  nice to replace `when-let' with `when' + `let'. This change costs
  only one loc.
>
> However, he did not mention the reasoning behind this, except a single
> massage I was able to find:
>
> https://orgmode.org/list/8737t0b2c9@nicolasgoaziou.fr
  ... you are not using `if-let' anywhere if this patch. Besides, we still
  cannot use subr-x, since it is a 24.4 library, and, AFAIR, we didn't
  drop support for 24.3 yet.
>
> If supporting Emacs 24 is the only blocker for subr-x, it should be safe
> to use it.

Right, as far as I understand, support for Emacs 24.3 was the main
reason to avoid it; subr-x.el wasn't added until Emacs 24.4, when it was
renamed from helpers.el.  (There may be the general stylistic question
of whether to use when-let{,*} and friends, but that's not relevant in
this context.)

I've pushed 04d9d4b3d, but please feel free to adjust as needed if some
other reason to avoid loading subr-x surfaces.

recent org-export-copy-buffer incompatible with Emacs < 28

[Kyle Meyer]

Hi Ihor,

b45911d41 (org-export-copy-buffer: Prevent saving to disk, 2022-10-07)
uses `always', but that function isn't available until Emacs 28.1,
specifically 825aed11d26 (Add the `always' function, 2021-02-20).

Re: [BUG] Re: 98e168b48 Add compatibility wrapper for string-clean-whitespace (Emacs 26 compatibility) [9.6-pre (release_9.5.5-920-g057193 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Max Nikulin writes:

> On 07/10/2022 12:14, Ihor Radchenko wrote:
>> 
>> The following commit adds `string-trim', which is not yet available in
>> Emacs 26.
>
> It is available in Emacs-26, however (require 'subr-x) should be added.
>
> There is `org-trim' and despite it is less generic, likely it can be
> used if subr-x is avoided for some reason.

Ihor, sorry for overlooking that.  As Max mentions, indeed string-trim
used to be in subr-x.  It's been available since Emacs 24 and was
relocated with Emacs 28's a4ececf004e (Move string-trim functions to
subr.el, 2021-03-24).

I won't be at my computer much today or tomorrow, but, when I get a
chance, I'll plan to add something like

  (eval-when-compile (require 'subr-x))  ; Emacs < 28

And of course please feel free to beat me to it and fix it however you
see fit.  Thanks.

Re: Attempting to create orgcard.org

[Kyle Meyer]

Bastien writes:

> Timothy  writes:
>
>> I’m trying to make a .org refcard. 
>
> Is it intented to replace orgcard.tex at some point?  I believe we
> should stick to using the same format for Org than for Emacs.  If this
> is doable via an .org file that is easier to maintain, that's good.

Something to consider: orgcard.tex is included in the Emacs repo and
fits into their refcard machinery.  If the source changes from .tex to
.org, the .org file must be included in the Emacs repo, as is done with
the .org of the manual now (bug#45143, bug#46837).  Doing so would
involve extra setup and handling on the Emacs side.  Even if someone on
the Org side volunteers to do that work, another case of special
handling probably wouldn't be received warmly.

Re: Getting rid of org-install.el

[Kyle Meyer]

Stefan Kangas writes:

> If we do it your way, does someone need to remember to delete the file
> manually when the time comes to move the emacs.git master branch to
> the latest Org release?  Or will that be done automagically?

My script for syncing the Org tree to the Emacs's does

  rm "$emacsrepo"/lisp/org/*.el
  cp "$orgrepo"/lisp/*.el "$emacsrepo"/lisp/org/

so that deletions/renames on Org's side are propagated.

Those aren't too frequent, but of course still need to be accounted for:

  $ git rev-parse HEAD
  6dc785288d3514af4071f210dac0a18c14a6c45b

  $ git log --since=2015 --format='%cs %s' --diff-filter=D --no-renames \
bugfix -- 'lisp/*.el'
  2021-09-28 lisp/ob-stan.el: Delete
  2021-09-26 Move some ob-*el files to the new org-contrib repo
  2019-03-10 Prefix link-related libraries filenames with "ol"
  2018-10-03 org-keys: Extract key bindings into their own library
  2017-08-18 Remove ob-scala.el

Re: Getting rid of org-install.el

[Kyle Meyer]

Stefan Kangas writes:

> org-install.el has been obsolete for more than 10 years.
>
> To finally get rid of this file, I put it to you that all we need to do is:
>
> 1. Move it in emacs.git from lisp/org/org-install.el to
> lisp/obsolete/org-install.el
> 2. Delete the file from org-mode.git

In my view it'd be better to drop the first item.  Org has removed
plenty of obsolete features in its time, but searching the emacs.git
history, I can't find a case where an Org-related file has been in
lisp/obsolete/.  I'd vote against setting that precedent, as I don't
want to introduce any more discrepancies between the Org files in
org-mode.git and emacs.git than necessary.

Re: [PATCH] Re: ox-latex table tabbing support.

[Kyle Meyer]

Thanks for the follow-up patch.

Daniel Fleischer writes:

> Subject: [PATCH] lisp/ox-latex.el: tabbing code refactor
>
> * lisp/ox-latex.el: documentation, indentation, cleaning
> (org-latex-table)
> (org-latex--align-string-tabbing)
> (org-table--org-tabbing)

This format doesn't quite align to the conventions.  Here are two
examples:

,[ https://orgmode.org/worg/org-contribute.html#commit-messages ]
|  * lisp/org-capture.el (org-capture-set-plist): Make sure txt is a
|  string before calling `string-match'.
|  (org-capture-templates): Fix customization type.
`

,[ 
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs
 ]
| * lisp/term.el (term-emulate-terminal): Avoid errors if the whole
| decoded string is eight-bit characters.  Don't attempt to save the
| string for next iteration in that case.
| * test/lisp/term-tests.el (term-decode-partial)
| (term-undecodable-input): New tests.
`

[...]
> +  (or (org-export-read-attribute :attr_latex table :align)
> +  (let* ((count
> +  ;; Count the number of cells in the first row.
> +  (length
> +   (org-element-map
> +   (org-element-map table 'table-row
> + (lambda (row)
> +   (and (eq (org-element-property :type row)
> +'standard)
> +row))
> + info 'first-match)
> +   'table-cell
> + (lambda (cell) cell

Fine as is, but (lambda (cell) cell) could be reduced to #'identity

> + ;; Calculate the column width, using a proportion of
> + ;;the documets textwidth.

nit: missing space before "the"

typo: documets -> document's

> +(defun org-table--org-tabbing (table contents info)
> +  "Return tabbing environment latex code for Org table.

Perhaps s/latex/LaTeX/ for consistency?

Otherwise, looks good to me.  Thanks again.

Re: ox-latex table tabbing support.

[Kyle Meyer]

Ihor Radchenko writes:

> Daniel Fleischer  writes:
>
>> Thank you very much for the patch. It was merged to master in 4a0d951c.
>> Also, you were added to the orgmode contributes at
>> https://orgmode.org/worg/contributors.html.
>>
>> Thanks for the contribution.
>
> This commit triggers
>
> In org-latex--align-string-tabbing:
> ox-latex.el:3713:54: Warning: Unused lexical variable `align'
>
> Looking at the code, it does not look like align variable serve any
> purpose. Can someone please double check if the patch is working as
> intended?

Thanks for flagging this, Ihor.  I was just glancing at this commit
(4a0d951c6) due to seeing this warning.  It's doing

  (let ((align ...))
(setq align ...))

where the align value is returned, so the align binding can be dropped
altogether.

Daniel, in addition to that, there are at least a few other issues with
4a0d951c6 that should be addressed:

 * the first line of the new docstrings should be a complete sentence.

   For example

 Return an appropriate LaTeX alignment string, for the
 latex tabbing environment.

   should be changed to something like

 Return alignment string for LaTeX tabbing environment.

   See (info "(elisp)Documentation Tips")

 * the indentation is off in several places, including the start of the
   docstrings.  Please indent the code with, e.g., indent-region.

 * one of org-table--org-tabbing's parameters is a typo (contenst),
   which it looks like Ihor pointed out in an earlier review

 * comment typo: documets

 * several spots put opening and trailing parentheses on their own line

   That goes against the usual conventions of this repo:

 $ git grep '^ *)' '*.el' | wc -l
 42
 $ git grep '( *$' '*.el' | wc -l
 17

 * rather than doing something like

 (let ((x ""))
   (setq x )
   ...)

   just do

 (let ((x ))
  ...)

   And consider whether it's worth adding a binding at all rather than
   inlining the code.

   As an extreme case, org-table--org-tabbing does

 (let ((output (format ...)))
   output)

   rather than

 (format ...)

Re: [BUG] ERR_CERT_DATE_INVALID for https://list.orgmode.org/

[Kyle Meyer]

Bastien Guerry writes:

> Kyle, do you have any clue?

Yes.  The SSL certs on my end are wired up to be automatically
refreshed.  In order for them to be in effect, though, I need to
manually restart nginx.  There's probably a better way to handle this,
but I just have a reminder.

Anyway, based on how the expiration dates for various domains line up,
it's usually okay if I don't act on that for a day or two, but in this
case it bumped right against the list.orgmode.org expiration.

Sorry about that (but you can't get your money back :>)

Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Kyle Meyer]

Max Nikulin writes:

> Confirmed
>
> Emacs copy of Org changed the way of calling `encode-time' as a result 
> interpretation of last nils returned by `org-parse-string' altered from 
> ignored to "no DST".
>
> Kyle, be aware of the conflict with `org-time-string-to-time' when you 
> will port emacs commit dd0727e1ec1f535b9b06be88173b4d3ccd55abcb
> Paul Eggert  Thu Dec 16 09:40:21 2021 -0800
> encode-time simplifications

Thank you, Max, for looping me into the discussion (and thanks, Ignacio,
for the initial report and debugging).

> New calling convention for `encode-time' exists since emacs-27.1, so it 
> is incompatible with yet supported emacs-26. [...]

>> So I guess this is an Emacs 29 bug? I didn't know the two repositories
>> could diverge like that. Should I report it to Emacs 29 maintainers?
>> Or can org-mode maintainers fix it in the Emacs repository?
>
> The problem is a consequence of grep-refactoring of Emacs code, but 
> likely it should be fixed at the Org side.

The long tail of 9e1b9fe62 (Port more time-related changes, 2019-08-18)

My suggestion:

  1. Send a report to bug-gnu-em...@gnu.org describing the issue.  Ask
 that Paul revert those changes.

 I can do this at some point this week.

  2. Audit and update the call sites on our side, along with some
 compatibility layer.

The first isn't necessary, but it avoids the problem living in the Emacs
master branch until the updated Org code base (main branch) is synced
with it (which hasn't started yet).

Re: bug-tracker: How to response/subscribe to a bug-thread

[Kyle Meyer]

c.bu...@posteo.jp writes:

> Side question: I can I monitor that thread/bug without being subscribed 
> to the list? The "dashboard" seems not to have any subscribe, monitor or 
> feed mechanism. The "Atom" feed (https://list.orgmode.org/new.atom) is 
> only for complete list not for one thread.

You can get an atom feed for a single thread using the /t.atom endpoint
(documented in ).

Example:

  https://list.orgmode.org/orgmode/12368452.sVpYeFqCzH@pluto/t.atom

Re: org-refile, org-capture byte-compiling failure with recent emacs-git

[Kyle Meyer]

Kyle Meyer writes:

> Kyle Meyer writes:
>
>> However, it seems unintended that with-demoted-errors would actually
>> error here now rather than give a warning; again, will need to take a
>> closer look.
>
> The patch at <https://debbugs.gnu.org/54225> demotes the error to the
> intended warning.

And Emacs's d52c929e3 has been ported to Org's bugfix branch to avoid
these failures regardless of whether the patch there is applied.

Re: org-refile, org-capture byte-compiling failure with recent emacs-git

[Kyle Meyer]

Kyle Meyer writes:

> However, it seems unintended that with-demoted-errors would actually
> error here now rather than give a warning; again, will need to take a
> closer look.

The patch at <https://debbugs.gnu.org/54225> demotes the error to the
intended warning.

Re: org-refile, org-capture byte-compiling failure with recent emacs-git

[Kyle Meyer]

Vladimir Lomov writes:

> Hello,
>
> org-refile and org-capture failed to byte-compile by emacs from git (commit:
> 8c8093aa6f20a7a4f3799cbdb9270cac013ef71d) with following messages:
>
> ...
>
> Compiling 
> /home/vladimir/pkgs/emacs-org-mode/src/emacs-org-mode/lisp/org-capture.el...
>
> In toplevel form:
> org-capture.el:1455:12: Error: Wrong number of arguments: (1 . 2), 4
>
> ...
>
> Compiling 
> /home/vladimir/pkgs/emacs-org-mode/src/emacs-org-mode/lisp/org-refile.el...
>
> In toplevel form:
> org-refile.el:566:17: Error: Wrong number of arguments: (1 . 2), 4

Thanks for reporting.

I'll need to look more closely, but this is very likely triggered by
d52c929e31f ((with-demoted-errors): Warn on missing `format` arg,
2022-02-04) on Emacs's side.  That commit is slated to be ported to the
Org repo but has been held for the time being with the rest of the
Org-touching commits that are in Emacs's master branch but not the
emacs-28 branch.

In d52c929e31f, the with-demoted-errors calls in org-refile and
org-capture were changed to use the format argument, which has been
available since Emacs 24.4.  So, the likely fix will just be porting
that commit.  However, it seems unintended that with-demoted-errors
would actually error here now rather than give a warning; again, will
need to take a closer look.

bug#49967: 27.2; org-copy-visible copies invisible text when there is a link

[Kyle Meyer]

close 49967 28.1
quit

Максим Бабушкин writes:

> The function org-copy-visible should copy visible text only, but it
> copies invisible text when there is a link in a header. For example, let
> an org buffer contains:
> [...]

Thanks for the detailed report, and sorry for the delayed response.
This should be fixed by f2833ff25 on Org's bugfix branch.

Note that Org's mailing list is the main place for development and
discussion of Org mode; you're more likely to get feedback by sending
bug reports to .

Re: How to enforce sub-scripts with {} only for HTML export?

[Kyle Meyer]

ed...@openmail.cc writes:

> What am I doing wrong? Thanks!
>
> * Emacs and Org configuration
>
> I am using this with ~emacs -q~:
>
> #+begin_src emacs-lisp
>  (setq
> ;; Use {} for super and subscripts
> org-export-with-sub-superscripts "{}")
> #+end_src

{} should be a symbol.  Try

  (setq org-export-with-sub-superscripts '{})

Re: ox-taskjuggler missing

[Kyle Meyer]

Greg Sullivan writes:

> Trying to export to taskjuggler (tj3) to get a gantt chart as in this
> description
> .
> But I can't find the taskjuggler exporter.
>
> emacs-version
> => GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
> Version 10.14.6 (Build 18G95)) of 2021-11-18
>
> org-version
> => Org mode version 9.4.4 (release_9.4.4 @
> /Applications/Emacs.app/Contents/Resources/lisp/org/)

Hmm, based on the version and location, that's presumably the builtin
Org that shipped with Emacs 27.2.  ox-taskjuggler.el has never shipped
with Emacs, so you must have been pulling it in from somewhere else.

Anyway, ox-taskjuggler.el along with the rest of contrib/ was removed
from the main Org repo in 0555665bb (Remove the contrib/ directory,
2021-05-03), part of the 9.5 release.

It's hosted at  for the time being
and is available from .

org-persist uses Emacs 28+ buffer-local-boundp

[Kyle Meyer]

Hi Ihor,

27215ac5b (org-persist: Handle undefined variables in elisp containers,
2022-02-13) added a call to buffer-local-boundp, which was introduced in
(what will be) Emacs 28.1.

Could you update org-persist-write:elisp to be compatible with older
Emacs versions (e.g., by inlining the short definition and adding a
comment about why buffer-local-boundp isn't used)?

Thanks.

bug#53393: 29.0.50; org mode timestamp C-c C-c not updating day of week

[Kyle Meyer]

[ I've reassigned this bug report so that new messages will be directed
  to the Org mailing list, where it's more likely to get a reply.  In
  the future, please consider using org-submit-bug-report or sending a
  message to emacs-orgmode@gnu.org directly. ]

Bruce E. Robertson writes:

> emacs -Q test.org
> cursor to "CLOCK:" line, C-c C-c
> total time updates but day of week does not change
> contents of test.org
> --
> * heading
> :LOGBOOK:
> CLOCK: [2022-01-17 Tue 10:29]--[2022-01-19 Tue 10:29] => 48:00
> :END:
> --
> typing C-c C-c does update total log time for line and recently did
> update the day of the week but no long does

I'm having trouble finding an Org version where it will update a
timestamp _within_ a clock line.  I tried it out with v9.1 and the day
of the week still isn't updated.  Outside of that context it will, as
org-ctrl-c-ctrl-c-hook gets through to its timestamp condition rather
than taking the clock branch.

If you can provide more details about a version where it did work,
showing it's a regression, I think you'll have a higher chance of
getting this fixed.

Anyway, at least for now, perhaps you could try something like this to
get the behavior you want:

  (defun my/update-clock-and-days ()
(when (eq (org-element-type (org-element-context)) 'clock)
  (let ((re (org-re-timestamp 'inactive)))
(save-excursion
  (goto-char (line-beginning-position))
  (while (re-search-forward re (line-end-position) t)
(backward-char)
(org-timestamp-change 0 'day))
  
  (add-hook 'org-ctrl-c-ctrl-c-hook #'my/update-clock-and-days)

With that, hitting `C-c C-c` on the clock line at

--8<---cut here---start->8---
* heading
:LOGBOOK:
CLOCK: [2022-01-17 Thu 10:29]--[2022-01-19 Sun 10:29] => 40:00
:END:
--8<---cut here---end--->8---

produces

--8<---cut here---start->8---
* heading
:LOGBOOK:
CLOCK: [2022-01-17 Mon 10:29]--[2022-01-19 Wed 10:29] => 48:00
:END:
--8<---cut here---end--->8---

Re: org-store-link does not work in gnus article mode (messages)

[Kyle Meyer]

Uwe Brauer writes:

> Hi  
>
> I thought this worked a while ago, but in a gnus article buffer I tried to 
> use org-store-link and received
>
> (Running Emacs Master and org-mode master (some weeks old))
>
> Debugger entered--Lisp error: (void-function org-fixup-message-id-for-http)
>   
> org-fixup-message-id-for-http("8ad92378cff625ebc8020dc45afdaadef484a3a3.ca...@web.de")

org-fixup-message-id-for-http was removed from Org before the 9.3
release (more specifically a486d9c, 2019-03-10) so your assumption that
a recent Org is at the front of your load-path is invalid.

Re: Export org to just body HTML

[Kyle Meyer]

Thomas Ingram writes:

> Hello,
>
> I was wondering if there is an easy to export an org file to HTML that
> is just the body of the HTML document.  Or to put it differently, just
> the HTML formatting that is actually displayed on the page and no extra
> metadata (no DOCTYPE, html, head tags etc).
>
> I often need this for inserting HTML into existing documents or for text
> boxes that support HTML formatting.

Have you tried selecting "Body only" when exporting to an HTML buffer?
With the default bindings, that'd be 'C-c C-e C-b h H'.

bug#52778: 29.0.50; refill-mode issues in org-mode

[Kyle Meyer]

Ihor Radchenko writes:

> Eli Zaretskii  writes:
>
>>> You are right. I do not actively watch Emacs bug tracker and I had no
>>> information about Rudolf's previous reports today.
>>
>> Did you look at them now?  I meant bugs 52771 and 52772.
>
> Yes. One is fixed already.

Thanks for fixing 52772.  I've marked it as done.  (One way to do that
is appending -done to the bug number in the debbugs address:
<52772-d...@debbugs.gnu.org>.)

> The other one should probably be forwarded to
> Org ML. However, I am not sure what is the right way to redirect
> messages from Emacs bug tracker to Org ML. Usually, Kyle takes care
> about this part.

Before replying to a message, you can reassign it the "org-mode" package
by sending a message to cont...@debbugs.gnu.org.  Here's an example:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38592;msg=10

However, looking at , it's already been
assigned to the org-mode package, so the reply I've sent should go to
Org's mailing list.

bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists

[Kyle Meyer]

Rudolf Adamkovič writes:

> Reproduction steps:
>
> 1. start "emacs -Q"
> 2. type "C-x C-f" and "test.org" and RET
> 3. type the following:
>
> - one
>  two
>
> - three
>  four
>
> 4. mark all with "C-x h"
> 5. type "M-q" to fill
>
> Actual:
>
> - one
>  two
>
> - three four
>
> Expected:
>
> - one two
>
> - three four

I can trigger the same behavior on my end.  I haven't stepped through
any code or searched the mailing list for related discussion, but it
looks like a bug to me.

(Unlike the initial post, this message should be forwarded to Org's
mailing list, and I've marked it as a confirmed bug for Org's
.)

bug#44833: 27.1; Org org-docview-open (wrong-number-of-arguments (2 . 2) 1)

[Kyle Meyer]

close 44833
quit

Kyle Meyer writes:

> I'm sorry you didn't get a response at the time, but it seems unlikely
> that you still have this issue because, as of Org's afd3b04ec (ol:
> Extend open tooling in link parameters, 2020-02-19), org-link-open
> handles the above error:
>
> ;; Function defined in `:follow' parameter may use a single
> ;; argument, as it was mandatory before Org 9.4.  This is
> ;; deprecated, but support it for now.
> (condition-case nil
> (funcall (org-link-get-parameter type :follow) path arg)
>   (wrong-number-of-arguments
>(funcall (org-link-get-parameter type :follow) path)))
>
> And that change made its way into the Emacs repo with f22856a5c54
> (Update to Org 9.4.1, 2020-12-13), which was a part of the 27.2 release.
>
> Can you confirm that the issue is resolved for you?

It's been close to two weeks, so I'll close this, but, if you are still
having this issue, please let us know.

bug#50218: 28.0.50; org-babel-tangle-file tangles code blocks starting with #+begin_src :tangle no

[Kyle Meyer]

Tassilo Neubauer writes:

> Hello,
>
> Here are the steps that led to code blocks being tangled I did not 
> expect to:
>
> emacs -Q
> C-x C-h: ~/org-roam/example.org
> content of example.org (excluding "):
> "
> #+begin_src emacs-lisp
> (setq some-emacs-lisp-variable t)
> #+end_src
>
> #+begin_src :tangle no
> ;;This line should not be in the elisp code
> #+end_src
> "

(Sorry for the delayed reply.  This message, unlike the initial post,
will be redirected to the Org list, where you're more likely to get a
response.)

Org sees the last block above as a source block of language ":tangle".
Here's what org-element-at-point reports:

  (src-block (:language ":tangle" :switches nil :parameters "yes"...)

org-lint will complain about this block:

 2 nil   Missing colon in header argument "yes"

And, were you to use a bare source block (i.e. drop ":tangle no"), it
would complain about a missing language:

 2 nil   Missing language in source block

So, I think the source block is mis-specified, and I'm not sure there's
much that Org should do here, but perhaps others will chime in with
their thoughts.

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Kyle Meyer]

Rudolf Adamkovič:

> I have a .org file with two kinds of src blocks:
>
> 1. sqlite blocks
> 2. bibtex blocks
>
> I want to execute all sqlite blocks with org-babel-execute-buffer.
>
> When I try to do so, org-mode complains:
>
> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>
> I know I can work around the problem (as one does in org-mode) with:
>
> #+property: header-args:bibtex+ :eval no
>
> Then, why not skip the irrelevant blocks, the ones with no execute functions, 
> by default?

I don't know, but I've reassigned this bug in order to redirect this to
the Org list, which serves as the primary place for Org development and
discussion.

bug#52547: 29.0.50; Confusing behavior of org-timer-set

[Kyle Meyer]

Rudolf Adamkovič:

> Reproduction steps:
>
> 1. run 'emacs -Q'
> 2. type M-; and then "(require 'org)"
> 3. type M-x and then 'org-timer-set'

This must be org-timer-set-timer; there's no org-timer-set in Org's
tree.

> 4. see 'How much time left? (minutes or h:mm:ss)'
> 5. type '10m'
>
> Expected: The timer runs for 10 minutes.
> Actual: The timer runs for 10 seconds.
>
> From the perspective of the user, this makes no sense.

Yes, it seems better to at least signal a user-error if the input
doesn't match the expected format.

Anyway, I'm redirecting this to the Org list.  Perhaps someone there
will be interested in improving this behavior or reviewing a patch that
does so.

> P.S. I would also expect auto-load on "org-timer-set".

org-timer-set-timer has been autoloaded since 4e2795413 (Add autoload
cookie to org-timer-set-timer, 2009-07-27).

bug#51365: 29.0.50; org-mode: modification-time error with git controled file

[Kyle Meyer]

close 51365 28.1
quit

TAKAHASHI Yoshio writes:

> Hi,
>
> With git controled file,
> {{{modification-time(%Y-%02m-%02dT%02H:%02M:%02S+09:00, 1)}}}
> causes "Wrong type argument: stringp, " error.
>
> `org-macro--vc-modified-time' in org-macro.el should pass list of FILE
> to `vc-call', because `vc-git-print-log' expects list of file as its 1st
> argument.

Thanks for the report and fix.  This failure is new with Emacs 28,
specifically 3572613550f (Fix vc-git-state for filenames with wildcards,
2021-08-15).  Before that, passing a string instead of a list worked
okay because vc-git-print-log just passed its FILES argument untouched
to vc-git-command's FILE-OR-LIST.

> diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
> index b8d3373418..9e70844963 100644
> --- a/lisp/org/org-macro.el
> +++ b/lisp/org/org-macro.el
> @@ -368,7 +368,7 @@ org-macro--vc-modified-time
>   date)
>   (unwind-protect
>   (progn
> -   (vc-call print-log file buf nil nil 1)
> +   (vc-call print-log (list file) buf nil nil 1)
> (with-current-buffer buf
>   (vc-exec-after
>(lambda ()

Looks good to me.  I confirmed the bug and fix only with vc-git,
although the change looks appropriate for the other backends too:

  $ git grep -E '\(defun vc-.+-print-log'
  lisp/vc/vc-bzr.el:(defun vc-bzr-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-cvs.el:(defun vc-cvs-print-log (files buffer  _shortlog 
_start-revision limit)
  lisp/vc/vc-dav.el:(defun vc-dav-print-log (_url)
  lisp/vc/vc-git.el:(defun vc-git-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-hg.el:(defun vc-hg-print-log (files buffer  shortlog 
start-revision limit)
  lisp/vc/vc-mtn.el:(defun vc-mtn-print-log (files buffer  _shortlog 
start-revision limit)
  lisp/vc/vc-rcs.el:(defun vc-rcs-print-log-cleanup ()
  lisp/vc/vc-rcs.el:(defun vc-rcs-print-log (files buffer  _shortlog
  lisp/vc/vc-sccs.el:(defun vc-sccs-print-log (files buffer  _shortlog 
_start-revision-ignored limit)
  lisp/vc/vc-src.el:(defun vc-src-print-log (files buffer  shortlog 
_start-revision limit)
  lisp/vc/vc-svn.el:(defun vc-svn-print-log (files buffer  _shortlog 
start-revision limit)

So, I've added a commit message to above patch and applied it in your
name on Org's bugfix branch (888689f2b).

bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

close 52341
quit

Kyle Meyer writes:

> I suppose one solution would be to check for " " and translate that to
> the ?\s so that the remove is triggered.  I'll plan to apply the change
> below to Org's bugfix branch in a day or two unless the author of the
> above commit (+cc) or someone else has another suggestion.

Applied to the Org repo (4aca51fcb).

bug#52399: 28.0.60; easier access to ORG-NEWS

[Kyle Meyer]

Mike Kupfer writes:

> Finding ORG-NEWS seems harder than it should be.
>
> 1. The "Browse Org News" menu item (Org > Documentation > Browse Org
> News) isn't adequate, because it takes you to orgmode.org.  The package
> description (C-h P org RET) has the same problem.  If you're working
> offline, orgmode.org is not going to be available.  Also, it shows the
> news for the latest release, which might not be what you have installed.
> (The news for older releases is available at the bottom of the page, but
> it could be confusing if you don't notice that the news that is first
> presented is for a different release.)
>
> 2. I don't see a reference to ORG-NEWS in the Org mode section of the
> Info pages, much less an easy way to get to it.

These two look like something that would be dealt with on Org's side.
This report has been reassigned there, so perhaps someone on the Org
list will have thoughts or decide to work on a patch.

> 3. The entry in NEWS for the Org mode update mentions ORG-NEWS, but it
> doesn't say how to get to it.  (Yes, I know how to get to ORG-NEWS from
> NEWS.  Do we expect random users to understand the layout of an
> installed Emacs at that level of detail?)

And I guess this one is for Emacs's side at the time of the sync.

I was looking through the NEWS* files in the Emacs repo for guidance
from other packages, but I see mostly the same thing ("GNUS-NEWS",
"MH-E-NEWS", "ERC-NEWS", ...).  I guess there is one that's a little
different, though I'm not sure how helpful tacking on "./" is: "See the
file ./MH-E-NEWS for details".

Do you have any suggestions for what would be more helpful to put there?

bug#52392: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

forcemerge 52341 52392
quit

Bruce E. Robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
[...]

This looks like a duplicate of https://debbugs.gnu.org/52341 (which has
already received comments), so I'm merging the reports.

bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

Robert Pluim writes:

>>>>>> On Mon, 06 Dec 2021 20:48:46 -0500, Kyle Meyer  said:
> Kyle> Right, this stems from org-priority feeding " " to string-to-number 
> and
> Kyle> ending up with 0 instead of the ?\s (32) that's used downstream to
> Kyle> signal "remove".  The problem goes back to when support for numeric
> Kyle> priorities was added in Org v9.4's 4f98694bf (Allow numeric values 
> for
> Kyle> priorities, 2020-01-30).
>
> Kyle> I suppose one solution would be to check for " " and translate that 
> to
> Kyle> the ?\s so that the remove is triggered.  I'll plan to apply the 
> change
> Kyle> below to Org's bugfix branch in a day or two unless the author of 
> the
> Kyle> above commit (+cc) or someone else has another suggestion.
>
> That fixes part of the issue, but still when using numeric priorities,
> removal will be 'SPC RET' rather than 'SPC'.

If someone 1) uses numeric priorities and 2) has org-priority-lowest
above 9, read-string is used to prompt with "Priority M-N, SPC to
remove: ".  They need to use 'SPC RET' just as they need to use, say, '3
RET'.  That is, it's consistent with the prompt behavior for entering
the actual priorities.

Perhaps that should change in some way (though I'm not planning on
working on it myself), but in my view that behavior shouldn't be
conflated with SPC not being translated to "remove the priority".

bug#44687: 26.3; Link broken in inline comment

[Kyle Meyer]

tags 44687 wontfix
close 44687
quit

YH Tan writes:

> In org-mode,
>
> ```
> [[link]]@@comment:[[link]]@@
> # [[link]]
>
> * link
> ```
>
> I get the message "No Link Found" when clicking on the [[link]] within
> the inline @@comment:[[link]]@@.
>
> The link works fine with emacs -Q, but breaks after evaluating some
> init.el code.
>
> Problem is, I cannot pinpoint to the exact code that broke the link.

I'm sorry you didn't get a response at the time.

Your recipe starts complaining "No Link Found" as of Org's d3774fba7,
which was a part of the 9.2 release:

  Limit `org-open-at-point'
  
  * lisp/org.el (org-open-at-point): Do not open everything that looks
like a link, in particular in verbatim or code objects.  However,
still conveniently open links in comments, node properties and
keywords.

The Org bundled with Emacs 26.3 was 9.1.9, so the difference you
reported between your regular environment and 'emacs -Q' is very likely
explained by the above commit being included in the Org available from
ELPA but not yet included in the Org that shipped with Emacs 26.3.

My understanding is that no longer being able to open a link (or rather
text that resembles a link) in an export snippet is an intentional
consequence of that commit, so I'm closing this as wontfix.  (But fwiw
calling org-open-at-point-global rather than org-open-at-point should
give the behavior you're after.)

bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

bruce robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
> ** TODO [#0] test line
>
> 3. from M-x view-lossage:
>  C-c , ;; org-priority
>
> 4. mini-buffer displays:
> "Priority 0-31, SPC to remove: "
>
> 5. further in view-lossage:
> SPC   ;; self-insert-command
>;; exit-minibuffer
>
> 4. from *Messages* (and mini-buffer):
> Priority of current item set to 0
>
> 5. PROBLEM:
> I wanted to remove priority.
>
> 6. WORK-AROUND:
> set priority to 32. Then priority disappears. Perhaps this is because 32
> is space code or because I've set org-priority-default to 32.
> ( I spent a medium amount of time to find this behavior. )
>
> 7. SUGGESTION:
> rewrite org-priority to have a clear distinction between numbers and
> characters and whatever will be used to remove the priority.
> ( I gave a look at this but my emacs-fu is too weak. Or my time-fu is
> too small. )

Right, this stems from org-priority feeding " " to string-to-number and
ending up with 0 instead of the ?\s (32) that's used downstream to
signal "remove".  The problem goes back to when support for numeric
priorities was added in Org v9.4's 4f98694bf (Allow numeric values for
priorities, 2020-01-30).

I suppose one solution would be to check for " " and translate that to
the ?\s so that the remove is triggered.  I'll plan to apply the change
below to Org's bugfix branch in a day or two unless the author of the
above commit (+cc) or someone else has another suggestion.

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..998da0656 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11323,13 +11323,14 @@ (defun org-priority ( action show)
(setq
 new
 (if nump
- (let ((msg (format "Priority %s-%s, SPC to remove: "
-   (number-to-string org-priority-highest)
-   (number-to-string org-priority-lowest
-   (if (< 9 org-priority-lowest)
-  (string-to-number (read-string msg))
- (message msg)
- (string-to-number (char-to-string 
(read-char-exclusive)
+ (let* ((msg (format "Priority %s-%s, SPC to remove: "
+ (number-to-string org-priority-highest)
+ (number-to-string org-priority-lowest)))
+(s (if (< 9 org-priority-lowest)
+   (read-string msg)
+ (message msg)
+ (char-to-string (read-char-exclusive)
+   (if (equal s " ") ?\s (string-to-number s)))
   (progn (message "Priority %c-%c, SPC to remove: "
   org-priority-highest org-priority-lowest)
  (save-match-data

bug#44833: 27.1; Org org-docview-open (wrong-number-of-arguments (2 . 2) 1)

[Kyle Meyer]

Michael 1 writes:

> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
>   org-docview-open("file.odt::1")
>   org-link-open((link (:type "docview" :path "file.odt::1" :format bracket 
> :raw-link "docview:file.odt::1" :application nil :search-option nil :begin 
> 364 :end 453 :contents-begin 415 :contents-end 451 :post-blank 0 :parent 
> (paragraph (:begin 364 :end 454 :contents-begin 364 :contents-end 454 
> :post-blank 0 :post-affiliated 364 :parent nil nil)
>   org-open-at-point(nil)
>   funcall-interactively(org-open-at-point nil)
>   call-interactively(org-open-at-point nil nil)
[...]
> Can you reproduce the error?
> Is there any way to fix this behavior?

I'm sorry you didn't get a response at the time, but it seems unlikely
that you still have this issue because, as of Org's afd3b04ec (ol:
Extend open tooling in link parameters, 2020-02-19), org-link-open
handles the above error:

;; Function defined in `:follow' parameter may use a single
;; argument, as it was mandatory before Org 9.4.  This is
;; deprecated, but support it for now.
(condition-case nil
(funcall (org-link-get-parameter type :follow) path arg)
  (wrong-number-of-arguments
   (funcall (org-link-get-parameter type :follow) path)))

And that change made its way into the Emacs repo with f22856a5c54
(Update to Org 9.4.1, 2020-12-13), which was a part of the 27.2 release.

Can you confirm that the issue is resolved for you?

Re: org-sort random

[Kyle Meyer]

(Please don't drop the list.)

Vikas Rawal writes:

> That is, just press RET?

I think that depends on the completion framework.  With the default
completion, yes, I think RET should do it.  With ivy, it's instead
ivy-immediate-done (C-M-j).  I'm not sure offhand about other
frameworks.

> If I do that, it just reverses the existing order. No randomisation
> happens.

Dunno.  Seems to work on my end (release_9.5.1-188-g27f26f782).

* h
** a
** b
** c
** d
** e
** f
** g
** h
** i
** j
** k
** l

With point on h and vanilla Emacs:

- C-c ^ f
- random
- RET

* h
** f
** e
** h
** i
** g
** j
** k
** b
** c
** d
** a
** l

Re: [PATCH] Fix regex for determining image width from attribute

[Kyle Meyer]

Matt Huszagh writes:

> Timothy  writes:
>
>> I’ve just pushed the change I described in 4514a32. This improves the
>> interpretation of :width attributes and makes a value of “t” work as 
>> discussed.
>> I have not prioritised #+attr_org for now, but that sounds like a change we
>> could make in the future.
>
> Thanks Timothy. However, I think this change may have some issues. It
> seems that it unbalances parentheses. This also no longer sets width
> (so, e.g., (floatp width) won't work). Maybe attr-width was intended to
> be renamed to width? Are you seeing the same?

I'm not sure either, but this syntax error brings down the whole tree,
so I've pushed 27f26f782 to resolve it.  Timothy, please check my guess
at what the intended code was.

Re: Invalid read syntax errors compiling orgmode from git repository

[Kyle Meyer]

JG writes:

> commit 4514a324c86a408951a0553a390a01981d61c367 (HEAD -> main, origin/main, 
> origin/HEAD)
[...]
> In toplevel form:
> org-agenda.el:50:1: Error: Invalid read syntax: ")", 50, 14
> Compiling /home/etest/org-mode/lisp/org-archive.el...
[...]

Thanks for reporting.  The syntax error was introduced by the commit you
referenced and is fixed with 27f26f782.

Timothy, please look over my change to confirm that it matches the
change you intended to make in 4514a324c.

Re: org-sort random

[Kyle Meyer]

On 11/22/21 07:40:35 +0530, Vikas Rawal wrote:
> I am trying to sort a sub-tree of headings randomly. But `C-c ^ f
> random RET` asks for a "function for comparing keys". What am I
> supposed to do?

Here's the prompt:

  Function for comparing keys (empty for default `sort-subr' predicate):

And here's what sort-subr's docstring says about the behavior of the
default predicate:

  If PREDICATE is nil, comparison is done with ‘<’ if
  the keys are numbers, with ‘compare-buffer-substrings’ if the
  keys are cons cells (the car and cdr of each cons cell are taken
  as start and end positions), and with ‘string<’ otherwise.

That sounds like that should handle random's return value fine, so try
entering an empty string at that prompt.

Re: test-org-cite/main-affixes failure

[Kyle Meyer]

Nicolas Goaziou writes:

> Kyle Meyer  writes:
[...]
>> Does the current version of the test (no space) pass on your end?
>
> No idea. I haven't been able to run any test during the past week, at
> least (due to a silly error about missing ob-vala).

Hmm, after ob-vala.el was removed from the repo, I believe I saw a
similar failure and needed to remove "vala" from the BTEST_OB_LANGUAGES
value in local.mk.

> Anyway, you're certainly right about the fix. You can push it.

Okay, thanks for the confirmation.  Pushed.

test-org-cite/main-affixes failure

[Kyle Meyer]

Hi Nicolas,

test-org-cite/main-affixes, added in ad4028286 (oc: Refactor affixes
extraction, 2021-11-03), is failing on my end:

  $ BTEST_RE=main-affixes make test-dirty
  [...]
  Test test-org-cite/main-affixes condition:
  (ert-test-failed
   ((should
 (equal '...
(org-test-with-temp-text "[cite:@key1 post1;@key2 post2; global post]" 
...)))
:form
(equal
 (nil "global post")
 (nil
#(" global post" 0 12 ...)))
:value nil :explanation
(list-elt 1
(arrays-of-different-length 11 12 "global post"
#(" global post" 0 12 ...)
first-mismatch-at 0
 FAILED  1/1  test-org-cite/main-affixes (0.009342 sec)
  [...]

Adding a space to the expected SUFFIX (as in the diff below) makes the
test pass for me and looks to be consistent with some of the other cases
in that test.

Does the current version of the test (no space) pass on your end?


diff --git a/testing/lisp/test-oc.el b/testing/lisp/test-oc.el
index c700780fe..896870303 100644
--- a/testing/lisp/test-oc.el
+++ b/testing/lisp/test-oc.el
@@ -286,7 +286,7 @@ (ert-deftest test-org-cite/main-affixes ()
   (org-test-with-temp-text "[cite:global pre;pre1 @key1;pre2 @key2]"
 (org-cite-main-affixes (org-element-context)
   (should
-   (equal '(nil . ("global post"))
+   (equal '(nil . (" global post"))
   (org-test-with-temp-text "[cite:@key1 post1;@key2 post2; global 
post]"
 (org-cite-main-affixes (org-element-context))
 

Re: Problems generating the org-mode documentation

[Kyle Meyer]

Hoffmann, Jobst writes:

> But I think I found the culprit:
>
> Line 17568 of org.texi reads:
>
> @kindex C-c C-x @
>
> and @ starts a command, which leads to the stack overflow.
>
> Line 17568 of org.texi should read
>
> @kindex C-c C-x @@
>  
> witha doubled @ at the end of the line and after applying this change
> org.texi the documentation org.pdf can be generated without any error.

Marco Wahl fixed this entry a few days ago on the bugfix branch:
37791bb4f (org-manual: Fix one kindex entry, 2021-10-18).

Re: org-table-blank-field key binding removal

[Kyle Meyer]

Bastien Guerry writes:

> I suggest we add a news entry in etc/ORG-NEWS in the bugfix branch for
> the change to be advertized for 9.5.x users.
>
> Can anyone do that?

Done in 9bc3a2b98.

Re: org-table-blank-field key binding removal

[Kyle Meyer]

Michael Brand writes:

> The change is not announced in ORG-NEWS. I think it should be in Version 9.4.

Right, I agree this change should have come with a NEWS entry, though
0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
is from the 9.5 release not 9.4.

However, 9.5 is out, and my understanding is that released NEWS sections
should not be substantially modified in most cases
().  I'll leave it to
the author of the original change and Bastien to decide if they want to
make an exception in this case.

test-org-cite/list-citations failure (was: Citation not inserted as 1st item in footnote ...)

[Kyle Meyer]

Hi Nicolas,

Nicolas Goaziou writes:

> Nicolas Goaziou  writes:
>
>> This allows one to insert a citation in the middle of the citation
>> number, which is not desirable either. IOW, an additional check is
>> required.
>
> I think this is now fixed. Thank you.

It looks like this commit introduced a test failure.  Starting with
7d22dca54 (oc: Fix citations in footnotes when using biblatex back-end,
2021-10-06), test-org-cite/list-citations fails on my end (Emacs 27.2):

--8<---cut here---start->8---
Test test-org-cite/list-citations condition:
(ert-test-failed
 ((should
   (equal '...
(org-test-with-parsed-data "Text[fn:1]
[fn:1] [fn:2][cite:@a]

[fn:2] [cite:@b]" ...)))
  :form
  (equal
   ("b" "a")
   ("a"))
  :value nil :explanation
  (proper-lists-of-different-length 2 1
("b" "a")
("a")
first-mismatch-at 0)))
   FAILED  1/1  test-org-cite/list-citations (0.015186 sec)
--8<---cut here---end--->8---

Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Kyle Meyer]

No Wayman writes:

> Subject: [PATCH] lisp/org.el: (org-save-all-org-buffers): Prevent `org-mode'
>  reload
>
> * lisp/org.el: (org-save-all-org-buffers): Ensure `save-some-buffers' PRED 
> returns boolean.
>
> As of this upstream commit:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a
>
> `save-some-buffers' will call its PRED argument if it returns a function.
> Since (derived-mode-p 'org-mode) returns the symbol org-mode,
> and org-mode is a function, org-mode is reloaded in modified Org
> buffers when calling `org-save-all-org-buffers'. Among other
> undesirable behavior, this will cause the buffer's visibility to be
> reset to its initial visibility.

Thanks for the analysis and fix.

  To git.savannah.gnu.org:/srv/git/emacs/org-mode.git
 11f450da8..b71474ff7  bugfix -> bugfix

Re: org-table-blank-field key binding removal

[Kyle Meyer]

On 10/05/21 21:49:22 -0500, Alan Wehmann wrote:
> On 2/5/21 in this email list Carsten Dominik suggested removing the
> key binding C-c  for "org-table-blank-field".  That got
> implemented for Org-9.5, but the Info file didn't get changed, so it
> still says:
>
> ‘C-c ’ (‘org-table-blank-field’)
>  Blank the field at point.
>
> in node (org) Built-in Table Editor

Thank you for catching that.  I've updated the manual in 6874af872.

> In my own usage of tables I use this key binding a lot, so I am going
> to figure how to restore it.

Sorry about that.  You can restore it on your end by putting something
like this in your config:

  (define-key org-mode-map (kbd "C-c SPC") #'org-table-blank-field)

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Kyle Meyer writes:

> Rudolf Adamkovič writes:
>
>> When I try to export HTML with APA/CSL citations (C-c C-e h o), 
>> Emacs says:
>>
>>> The default CSL locale file 
>>> /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/etc/csl/locales-en-US.xml
>>>  
>>> doesn’t exist or is unreadable

This is hopefully resolved with bb209cd5ab (Update to Org
9.5-30-g10dc9d, 2021-10-02) in the Emacs repo.

Re: Grabbing the link to a message on the archive

[Kyle Meyer]

Max Nikulin writes:

> On 02/10/2021 21:26, Ihor Radchenko wrote:
[...]
>> It can be parsed from the html.  Something like below (it is my
>> home-made parser, but I think the idea should be clear):
>> 
>> (org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form 
>> :tag 'input :attr '(name . "d") :attr 'value))
>
> Thank you, Ihor. I did not expect such funny form of obfuscation. Since 
> even author names are hidden in search results, I believed that 
> message-id should be considered even more confidential to put it into 
> page code.

Any obfuscation presented by https://lists.gnu.org is misleading.  Bots
don't have any issue getting addresses from that domain:

  curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2021-09

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Bruce D'Arcus writes:

> Sorry; I wasn't clear.
>
> What I meant is that etc/styles was also not synced.

Right, some of the non-lisp files get moved around directory-wise
between the Org and Emacs repos.  Just in case it didn't stick out in
the snippets from my message upstream, the same files are there on both
sides:

  $ git -C org-mode ls-tree -r release_9.5:etc/styles
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README

  $ git -C emacs show --no-patch --format="%s (%ch)" bf9ec3d91a
  Update to Org 9.5 (Wed Sep 29 23:21)

  $ git -C emacs ls-tree bf9ec3d91a:etc/org
  100644 blob d0c98a3e51c079e74780d54289b09ba8ba52ac64  
OrgOdtContentTemplate.xml
  100644 blob 1a8edee99b4ccbbb18321091a7530afee660906a  OrgOdtStyles.xml
  100644 blob 07126fc31ba60103032e075e7cfdf81569e324c9  README

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Bruce D'Arcus writes:

> On Sat, Oct 2, 2021 at 1:24 AM Kyle Meyer  wrote:
>
>> Is there a reason to avoid updating to the latest version?
>
> No; updating them makes sense.

All right, thanks.  I've updated these files to latest versions in
06ab36eb0.

Re: [org-cite] Testing on macOS, XML file missing

[Kyle Meyer]

Rudolf Adamkovič writes:

> I compiled Emacs from "master" (2e92f90a5d) to try the new 
> citations.
>
[...]
>
> When I try to export HTML with APA/CSL citations (C-c C-e h o), 
> Emacs says:
>
>> The default CSL locale file 
>> /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/etc/csl/locales-en-US.xml
>>  
>> doesn’t exist or is unreadable
>
> (I checked, and no 'etc' directory exists in 'lisp/org'.)

Thanks for the report.  Indeed I didn't check for new files outside of
lisp/, and etc/csl/ wasn't synced to Emacs.  Though even if those files
were present, you would have seen the same failure due to the way things
are written on our end.

I've pushed a set of commits to the Org repo (60b178e59, 0f11a44e0, and
9cc7f8bd1) that should prepare things on our end.  And I've done a local
sync to Emacs and verified that org-cite-csl--etc-dir looks to point to
the right place when running from Emacs and when installed to the
system.

Before we sync these etc/csl/ files to the Emacs repo (which hopefully
won't be a point of contention), I have a question about these files.
After a bit of digging, I traced their origin.  As I say in 9cc7f8bd1
(etc/csl: Add a README in preparation for Emacs sync):

  I did not add these files, but I have verified that
  
   - etc/csl/chicago-author-date.csl is identical to
 9821a884d2cbf919a064426999b05aa78e98da8d:chicago-author-date.csl
 from https://github.com/citation-style-language/styles
  
   - etc/csl/locales-en-US.xml is identical to
 a2b76b20ee120979ec66cfdcfa798b36fc5a7f0b:locales-en-US.xml from
 https://github.com/citation-style-language/locales

However, both of those files have newer versions.

  $ git log --oneline --format="%ch | %h %s" 9821a88.. -- 
chicago-author-date.csl
  Sun Sep 19 03:19 | ccb71844f Update chicago-author-date.csl (#5605)
  Apr 26 2020 | a78997329 Chicago: Uppercase "Presentated at" if no `genre` 
(#4729)
  Aug 13 2019 | d9852a293 Update chicago-author-date.csl and other author date 
variants (#4250)
  Jan 3 2019 | 246ce5fdf Chicago: Correct dictionary/encyclopedia entries
  May 21 2018 | 9296c8c15 Fix redundant terms (#3517)
  May 13 2018 | e4db3699d update chicago-author-date.csl; close issue #3386 
(#3455)
  Jan 25 2018 | f601d1af5 Fix missing space before locators. (#3288)
  Dec 6 2017 | 04cbd1787 Reindent/reorder

  ---

  $ git log --oneline --format="%ch | %h %s" a2b76b2.. -- locales-en-US.xml 
  Dec 29 2017 | 9a4eb48 Replace some usernames by real names
  Dec 29 2017 | f01d92a Drop email addresses from translator tags
  Dec 29 2017 | f6fa898 Add translators from git log to the locale files.

Is there a reason to avoid updating to the latest version?

Re: org-element.el change in emacs.git

[Kyle Meyer]

Adam Porter writes:

> I noticed this recent commit on emacs.git making a change to
> org-element.el:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332

Thanks for the heads up.

I monitor Org-related changes to the Emacs repo and port them to Org's.
Entering into Emacs release periods, I tend to look at least once a day
so that porting doesn't hold up cutting a bugfix release and syncing.
Other times, it's not as frequent, but usually not less than once a
week.

None of that is to say that flagging an important commit isn't
appreciated.  Just setting expectations about what the normal intake
looks like.

(Fwiw a log of the considered commits is available at
.)

> I don't see that change in org-mode.git, and it seems like it could be
> an important one, so I wanted to make sure it doesn't go unnoticed.

It came in with c763b9ae6 (Backport commit 58102466e from Emacs,
2021-09-30), and it looks like it was merged into the bugfix branch
about ten minutes before your message landed, but I probably _pushed_ a
bit after you hit send :)

Re: Switching to new Git repositories

[Kyle Meyer]

No Wayman writes:

> Out of curiosity I ran this against the repo to see if the 
> "Version" metadata had always followed its current convention:
>
> git grep "Version:" $(git rev-list --all) -- lisp/org.el
>
> Looks like the "-dev" suffix goes back to "9.4-dev" and before 
> that we have "8.4-git" and "6.08-pre01".
> I'm not sure what Org's convention is here, but the patsubst could 
> be adjusted to be more flexible if necessary.

Thanks for checking.  I think just handling -dev is probably good
enough.

> Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos

Pushed:

  To git.savannah.gnu.org:/srv/git/emacs/org-mode.git
 c9dc6603a..9a4a24a94  main -> main

(It's not needed on the bugfix branch given -dev isn't used in the
header there.  Plus I think the 9.5 release is expected before another
release from maint/bugfix.)

Thank you for fixing my mistake.

Re: Switching to new Git repositories

[Kyle Meyer]

On 09/23/21 17:17:48 -0400, No Wayman wrote:
>> Sounds like a weird issue.  I don't think this 9.5-dev tag is 
>> something from the Org repo.
>
> There is a bug in mk/targets.mk introduced by 61336f80dc.

Quoting that commit message for context:

  mk/targets.mk: Add version fallback for tag-less repos
  
  * mk/targets.mk (ORGVERSION, GITVERSION): Get version from lisp/org.el
  header if it can't be retrieved from git-describe.
  
  As of elpa.git's ee03829f90 (Finalize the new master branch,
  2020-12-14), org-release and org-git-version are empty strings in
  https://elpa.gnu.org/packages/org-*.tar files.  This is because the
  new setup executes `make autoloads info' in an elpa.git worktree with
  an Org branch checked out, but elpa.git of course doesn't have Org's
  release tags.
  
  Maintaining the org.el version header has been a point of contention
  in the past [1], but the header has been there for a while now.  Use
  it to avoid the above elpa.git issue.  In the case of the master
  branch, the org-release value generated in a tag-less repo will have a
  different version than the one from a regular repo because org.el's
  version header has a "-dev" suffix, but that's still better than an
  empty version.
  [...]

> As others have pointed out, the new repository does not have tags.
> As a fallback, org.el's version is read in it's header.
> However, it looks like Kyle forgot to trim that string so we get 
> ORGVERSION set to "9.5-dev" instead of "9.5".

I of course can't say for sure, but based on my commit message (in
particular the last paragraph), it sounds like I was aware of the
discrepancy but didn't realize it'd cause the downstream "Invalid
version syntax" issue mentioned by Bill in
.

> This causes `org-version' to return an incorrect version string.
>
> The attached patch addresses the issue in the makefile.

Thanks.

> Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos
>
> * mk/targets.mk (ORGVERSION, GITVERSION): properly generate ORGVERSION.

I think it'd be better to say something more specific about the change
rather than say "properly" and assume the reader knows what the writer
has in mind.

> Fix bug introduced 61336f80 which caused ORGVERSION to be generated as
> "Major.Minor-dev" instead of "Major.Minor" in tag-less repos.

Please say what the bug is.  Can you give a sparse outline of the call
chain for the error mentioned in Bill's message?

> -ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \
> -  --visit lisp/org.el --eval '(princ (lm-header "version"))')
> -GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
> +ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
> +  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> +GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD))

It looks like you've unintentionally added a ')' to the end of the
GITVERSION line.

Another approach would be to update org.el's version to contain
something that still signals "-dev" but won't trigger the "Invalid
version syntax" (which, based on grepping the Emacs repo, is signaled by
version-to-list).  But given that in the current setup a clone with tags
wouldn't use the header version, stripping -dev for consistency sounds
like the way to go.

org-attach-sync uses directory-empty-p (new in Emacs 28)

[Kyle Meyer]

Hi Marco,

In 61e083732 (org-attach: Possibly delete empty attach directory,
2021-07-09), you added a call to directory-empty-p.  This function was
introduced in Emacs's 0806075520 (Add directory-empty-p and new argument
COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a
release.

Could you update org-attach-sync to avoid using directory-empty-p (e.g.,
by inlining it or by adding a compatibility alias)?

Thanks.

[RFH] thoughts on porting an Emacs etc/schema/ change

[Kyle Meyer]

I'm trying to figure out how to port changes to etc/schema/ files in the
Emacs repo back to the Org repo.  I'd appreciate feedback from anyone
who knows anything about the etc/schema/ files in Org's tree and/or
ox-odt.


Background
==

Org has a few files in etc/schema:

  org$ git ls-files --stage etc/schema
  100644 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e 0 
etc/schema/od-manifest-schema-v1.2-os.rnc
  100644 8d679d62e4ef1a21707250cf4cabcd5b657d7683 0 
etc/schema/od-schema-v1.2-os.rnc
  100644 f1e0ed7856f24c58488bbeac1df922a7d5100776 0 etc/schema/schemas.xml

Two of those are in Emacs's tree as is:

  emacs$ git ls-tree -r origin/emacs-27 -- etc/schema/ | grep od
  100644 blob 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e  
etc/schema/od-manifest-schema-v1.2-os.rnc
  100644 blob 8d679d62e4ef1a21707250cf4cabcd5b657d7683  
etc/schema/od-schema-v1.2-os.rnc

The contents of Org's etc/schema/schemas.xml, on the other hand, are
_added_ within Emacs's etc/schema/schemas.xml.

  org$ git show f1e0ed7856f24c58488bbeac1df922a7d5100776
  
  http://thaiopensource.com/ns/locating-rules/1.0;>




  

  emacs$ git show origin/emacs-27:etc/schema/schemas.xml | wc -l
  65

  emacs$ git show origin/emacs-27:etc/schema/schemas.xml | grep -i 
'opendoc\|od-'






Changes on the Emacs master branch
==

A commit on Emacs's master branch (author cc'd) makes changes to these
files.

  emacs $ git ls-tree -r master -- etc/schema/ | grep od
  100644 blob 87f84d1ea87e1e0eef759fac1bd7db74ce0a704e  
etc/schema/od-manifest-schema-v1.2-os.rnc

  emacs$ git show --numstat --format=%B f1f351def3d84813d2c4b2174dfef07b01bec058
  Update rnc to use Open Document's Relax-NG schema to version 1.3
  
  * Use the LibreOffice Relax-NG files since they include a hack to
 support 1.2.
  * rng source:
 https://raw.githubusercontent.com/freedesktop/libreoffice-core/master/
 schema/libreoffice/OpenDocument-schema-v1.3%2Blibreoffice.rng
  * translation to rnc with trang:
 trang -I rng -O rnc OpenDocument-schema-v1.3+libreoffice.rng \
 OpenDocument-schema-v1.3+libreoffice.rnc
  
  
  892 0   etc/schema/OpenDocument-schema-v1.3+libreoffice.rnc
  59145780etc/schema/{od-schema-v1.2-os.rnc => 
OpenDocument-schema-v1.3.rnc}
  5   1   etc/schema/schemas.xml

Here are the changes to schemas.xml:

  emacs$ git diff f1f351def3d84813d2c4b2174dfef07b01bec058^- 
etc/schema/schemas.xml
  diff --git a/etc/schema/schemas.xml b/etc/schema/schemas.xml
  index 7fd91b8c72..f8acb0d40c 100644
  --- a/etc/schema/schemas.xml
  +++ b/etc/schema/schemas.xml
  @@ -31,6 +31,10 @@
 http://relaxng.org/ns/structure/1.0; typeId="RELAX NG"/>
 http://thaiopensource.com/ns/locating-rules/1.0;
   uri="locate.rnc"/>
  +  
  +  
  +  
  +  
   
 
 
  @@ -59,7 +63,7 @@
   
 
 
  -  
  +  
 
   
   


Porting to Org's tree
=

So, coming back to the Org repo, I guess that'd be

  * delete the od-schema-v1.2-os.rnc file and add
OpenDocument-schema-v1.3.rnc

  * update the typeID line for od-schema-v1.2-os.rnc in Org's
etc/schema/schemas.xml to match the
OpenDocument-schema-v1.3+libreoffice.rnc line in the diff above

  * add the namespace lines to Org's etc/schema/schemas.xml (?)

But I know nothing about those files or ox-odt, so testing it on my end
would mostly be fumbling around to see if I spot any breakage when
exporting with ox-odt.

Does the above approach look reasonable?  Will it break ox-odt or be
problematic for some other reason?

Re: Org mode manual export

[Kyle Meyer]

Thomas S. Dye writes:

> Aloha all,
>
> The Org mode FAQ on Worg correctly reports that the Org mode 
> manual is written in Org mode, but it implies that it is exported 
> to texinfo using pandoc--"You can export .org files to texinfo 
> using Pandoc".
>
> I thought the manual was exported to texinfo with ox-texinfo, but 
> I don't know for certain.
>
> Can someone confirm how the Org mode manual is exported to 
> texinfo, please?

Yes, you're right that ox-texinfo is used.

In doc/Makefile there's

  org.texi orgguide.texi:   org-manual.org org-guide.org
$(BATCH)  \
  --eval '(add-to-list `load-path "../lisp")' \
  --eval '(load "../mk/org-fixup.el")'\
  --eval '(org-make-manuals)'

where org-make-manuals is defined in mk/org-fixup.el as

  (defun org-make-manuals ()
"Generate the Texinfo files out of Org manuals."
(require 'ox-texinfo)
(dolist (manual '("../doc/org-manual.org" "../doc/org-guide.org"))
  (find-file manual)
  (org-texinfo-export-to-texinfo)))

Re: tags-todo agenda shoud not ignore DONE items

[Kyle Meyer]

Bastien writes:

> Bastien  writes:
>
>> Confirming this as an issue, if someone wants to fix it.
>
> This should be fixed now with 823f9744e in maint, tags-todo should now
> include DONE headings.

823f9744e looks like a regression because it removes the distinction
between `tags' and `tags-todo'.  Consider the following file

--8<---cut here---start->8---
* h1   :atag:
* TODO h2  :atag:
* DONE h3  :atag:
* h4
* TODO h5
* DONE h6
--8<---cut here---end--->8---

and the following configuration

  (setq org-agenda-custom-commands
'(("1" tags "atag")
  ("2" tags-todo "atag")))

Before the above commit, 1 should show

  scratch:h1
  :atag:
  scratch:TODO h2   
  :atag:
  scratch:DONE h3   
  :atag:

and 2

  scratch:TODO h2   
  :atag:

That matches my expectations, though the request in this thread is that
2 includes "DONE h3" as well.

With 823f9744e, both 1 and 2 show

  scratch:h1
  :atag:
  scratch:TODO h2   
  :atag:
  scratch:DONE h3   
  :atag:

Note the inclusion of a non-TODO entry for 2 (tags-todo).

---

James Cash sent a followup patch to this in a detached thread:

  https://orgmode.org/list/87tuvyaopv@gmail.com

As I mentioned in that thread (<87361d7p3q@kyleam.com>) and
suggested in this thread (<87d061auiw@kyleam.com>), I think tags and
tags-todo should stay aligned with agenda's m/M, with tags-todo
excluding DONE items just as M does.

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Kyle Meyer writes:

> Ah, sorry for not writing that more clearly.  By the above, I wasn't
> saying that the ones I commented on were the _only_ ones I see with
> Emacs 24.5 on maint.

I've dealt with a few more.

 * ob-C.el:477:1:Error: Unknown upattern `(quote integerp)'

   Introduced by 38f87a26b (ob-C.el: Fix a number a regressions related
   to table parameters, 2021-04-29).

   Fixed by 8bd3bd093.

 * org-agenda.el:10851:1:Warning: the following functions are not known
   to be defined: [...] window-font-width

   I mentioned upthread (<87czubrqh6@kyleam.com>) that I didn't
   think this was easy to solve with a wrapper.  Instead I've added a
   fallback to the previous calculation, which was in action for a long
   time and is certainly better than a void-function error (94837fc6b).

 * Compiler-macro error for python-syntax-context: (void-function
   python-syntax--context-compiler-macro)

   I don't know what's going on here.  This is triggered by
   (python-syntax-context 'string) in ob-python.  That looks like it
   should work on Emacs 24, where python.el has
   python-syntax--context-compiler-macro.

   Despite the message from the compiler, evaluating
   (python-syntax-context 'string) directly seems to work as expected,
   so perhaps this doesn't actually cause ob-python breakage.

Aside from the harmless ol-eww warnings already mentioned, that leaves
the funcall-interactively instances.

Re: Transforming table and then exporting as CSV

[Kyle Meyer]

Pankaj Jangid writes:
[...]
> Same org file has multiple tables, so I am asking for “Table Name”. I
> want to do two improvements:
>
> 1. When asking for table name, I want to offer all the table names in
>the file as completion options.

You could collect names with something like

  (require 'subr-x)

  (let (names)
(org-table-map-tables
 (lambda ()
   (when-let ((name (org-element-property :name (org-element-at-point
 (push name names)))
 'quiet)
(nreverse names))

and then pass those as the collection to completing-read.

> 2. Current table at point as default

You could get that with

  (and (org-at-table-p)
   (save-excursion
 (goto-char (org-table-begin))
 (org-element-property :name (org-element-at-point

and pass that as the default for completing-read.

> 3. I want to run the function from command line. Like,
>
> --8<---cut here---start->8---
>emacs --batch enet_2021_22.org -l enet.el --eval="(enet-export 
> \"APR2021\")"
> --8<---cut here---end--->8---
>
>Do I need to change the (interactive...) part in any way to enable
>this?

I think that'd be the cleanest way, yes.  You could change

  (interactive "MTable Name: ")

into

  (interactive (list (completing-read ...)))

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Ihor Radchenko writes:

> Kyle Meyer  writes:
>
>> Here are a few notes on ones present in maint that I've glanced at.
>
> I confirm that there are no warning using Emacs 25.3.1 on maint.
>
> For Emacs 24.5.1, I see that following in addition to what you
> mentioned:

Ah, sorry for not writing that more clearly.  By the above, I wasn't
saying that the ones I commented on were the _only_ ones I see with
Emacs 24.5 on maint.

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Ihor Radchenko writes:

> I was recently testing Org mode using old Emacs versions. Running make
> on master fails with the following errors and warnings:

Here are a few notes on ones present in maint that I've glanced at.

> Compiling /home/yantar92/Git/org-mode/lisp/ol-eww.el...
>
> In org-eww-store-link:
> ol-eww.el:76:36:Warning: reference to free variable `eww-data'
>
> In end of data:
> ol-eww.el:182:1:Warning: the function `eww-current-url' is not known to be
> defined.

These are guarded by version checks.  Ideally the compatibility kludges
would be done in a way to avoid the warnings (e.g., with boundp/fboundp
guards) or at least wrapped in with-no-warnings, though harmless
warnings on Emacs 24 don't really matter too much at this point.

> In end of data:
> org-agenda.el:10851:1:Warning: the following functions are not known to be
> defined: funcall-interactively, window-font-width

Adding a compatibility function for window-font-width is tricky.  We
can't just add something like below to org-compat because font-info (C
code) wasn't added until Emacs 25.

  (if (fboundp 'window-font-width)
  (defalias 'org-window-font-width 'window-font-width)
(defun org-window-font-width ( window face)
  (with-selected-window (window-normalize-window window t)
(if (display-multi-font-p)
(let* ((face (if face face 'default))
   (info (font-info (face-font face)))
   (width (aref info 11)))
  (if (> width 0)
  width
(aref info 10)))
  (frame-char-width)

> In org-display-inline-images:
> org.el:16554:57:Warning: reference to free variable `image-map'

This warning is now gone (df84100d0), though functionally it was fine
due to a version check.

> In end of data:
> org.el:21292:1:Warning: the function `make-process' is not known to be
> defined.

This should be addressed by 869b7a21b.

Re: [PATCH] Fix numbering of captioned images

[Kyle Meyer]

Pablo Barraza Cornejo writes:

> Sounds good to me! I've modified the patch to reflect this change.
[...]
> Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering

Thanks.  Pushed (390063d8d).

Re: [PATCH] Fix numbering of captioned images

[Kyle Meyer]

Pablo Barraza Cornejo writes:

> When exporting to HTML, the exporter is supposed to check if there 
> are additional constraints over a paragraph using 
> `org-html-standalone-image-predicate'.  A misplaced quote causes 
> `org-html-standalone-image-p' to not apply them.

Thanks for catching the issue and for sending a patch.  This looks like
a regression introduced way back in 8.2.7 by ab1ce2a75 (ox-html: Fix
spurious "figure" divs on empty paragraphs, 2014-05-15).

> Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering.

The convention in this project is to leave off the trailing period from
the subject.

> * lisp/ox-html.el (org-html-standalone-image-p): Remove quote  which
> causes `org-html-standalone-image-p' to not check if 
> `org-html-standalone-image-predicate' is bound.

Please fill this line to ~70 characters (set in the repo's
.dir-locals.el).

>  (and (eq (org-element-type paragraph) 'paragraph)
> -  (or (not (fboundp 'org-html-standalone-image-predicate))
> +  (or (not (fboundp org-html-standalone-image-predicate))
>(funcall org-html-standalone-image-predicate paragraph))

This quote will indeed result in the fboundp call always returning nil:

  (let ((org-html-standalone-image-predicate #'org-html--has-caption-p))
(fboundp 'org-html-standalone-image-predicate))  ; => nil

  (let ((org-html-standalone-image-predicate #'org-html--has-caption-p))
(fboundp org-html-standalone-image-predicate))   ; => t

However, the proposed change will introduce another issue.
org-html-standalone-image-predicate is defined as

  (defvar org-html-standalone-image-predicate)

That means it's left uninitialized:

  (defvar my/foo)   ; => my/foo
  (boundp 'my/foo)  ; => nil
  (fboundp my/foo)  ; error: (void-variable my/foo)

What about returning to the boundp/fboundp combination that was in place
before ab1ce2a75?

  (and (boundp 'my/foo)
   (fboundp my/foo)); => nil
  
  (let ((my/foo #'ignore))
(and (boundp 'my/foo)
 (fboundp my/foo)))  ; => t

Re: Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Kyle Meyer]

Bastien writes:

> Hi Tom,
>
> Tom Gillespie  writes:
>
>>The 9.4 release has a bug where it will only tangle the first noweb
>> reference on a line.
>> This is also present at 9c31cba002a1ba93053aebea1f778be87f61ba06. It happens 
>> in
>> emacs-27 and emacs-28. The reproduction is below. Best!
>> Tom
>>
>> The expected content of oops-3.el should be 1 2 1, but is instead 1
>> <> <>.
>> C-c C-v C-t or C-c C-v C-v will show the issue.
>
> Do you still have this issue?  I cannot reproduce it here.

A patch upthread ()
was applied in 469ee6340 (ob-core: Fix handling of multiple noweb refs
in same line, 2020-09-15).

Re: [PATCH] org-manual.org: Fix syntax

[Kyle Meyer]

Cheong Yiu Fung writes:

> Subject: [PATCH] org-manual.org: Fix syntax
>
> * doc/org-manual.org (HTML export commands): Fix kbd representation

Thanks.  Pushed (58cacdf0e), adding a period after "representation".

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[Kyle Meyer]

Bastien writes:

> Hi,
>
> thanks for the patch, we do indeed need to move forward for this.
>
> Could you propose the patch against the master branch (not the maint
> branch, since this is not a bugfix) and perhaps fix *all* warnings?

Thanks, but these were already taken care of by 8c29cbdef (Backport
commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into master
with 664b65344.

Re: org-contacts.el use lexical-let not defined in cl-lib

[Kyle Meyer]

Michael Eliachevitch writes:

> Dear all,
>
> I'm not sure if this is the correct mailinglist for org-contrib
> bugs.

Thanks for the report.  Yes, this is the place [*].  stardiviner (+cc)
recently took over maintaining org-contacts.el.

> I found that org-contacts.el uses `lexical-let*` which is defined in
> `cl`, but it only requires `cl-lib` where it is not defined.
[...]
> My org version is release_9.4.5-321-ge641d3. However, I see that 
> on the master branch still uses lexical-let*.
>
> Is this a bug or some error in my configuration? Should I send an 
> email elsewhere or submit a bug-report? Because (require 'cl) is 
> deprecated, test solution would be to replace the lexical-let* 
> with something else like a normal let*, but I'm not confident 
> enough in my lisp to do this by myself.

This is a bug in org-contacts.el.  Loading cl was dropped in ea238b78f
(contrib: move a few libraries to cl-lib in place of compile-time cl,
2015-11-06), and, as you note, it's still needed for lexical-let.

I haven't looked at the org-contact's lexical-let call sites closely,
but I think the way forward is to move org-contacts.el over to lexical
binding and stop using anything from cl.el.

stardiviner, what do you think?


[*] ... though sometime soon the plan is to move contrib/ packages
elsewhere, at which point I guess it mostly will depend on who is
taking care of a given contrib/ package.

https://orgmode.org/list/87wnzfy60h@bzg.fr

Re: unable to resolve link to Gnus email

[Kyle Meyer]

Seb writes:

> Hello,
>
> Attempting to export with any exporter fails if document or a subtree
> thereof contains an email link, e.g. captured from a Gnus buffer:
>
> [[gnus:GroupName#EMAIL_ID][Email from John Doe]]
>
> I get the error:
>
> user-error: Unable to resolve link: 
> "gnus:Melanie#ef90b1cff5264135a82bff491006b...@cawnsmbme105.me.mbgov.ca"

Do you have ol-gnus loaded? [*]  It doesn't define an :export function,
but it's still important so that the link is recognized as a gnus link.
Otherwise org-export-resolve-fuzzy-link will handle it, signaling
org-link-broken.

Using your example

  
[[gnus:Melanie#ef90b1cff5264135a82bff491006b...@cawnsmbme105.me.mbgov.ca][Email 
from John Doe]]

here's what I see on my end (e641d3736) with no custom configuration.

Without ol-gnus loaded:

 * (org-element-property :type (org-element-context))  ; "fuzzy"
 * export fails with "Unable to resolve link"

With ol-gnus loaded:

 * (org-element-property :type (org-element-context))  ; "gnus"
 * export succeeds


[*] If you're not tweaking org-modules, it should be loaded by default.

Re: Bug: org-caputure fails, sometimes [9.3.7 (release_9.3.7-705-gea9463 @ /home/oub/emacs/site-lisp/packages/org/)]

[Kyle Meyer]

Uwe Brauer writes:

> I am running GNU emacs and org mode, whose versions are specified below.
> Sometimes when being in a gnus message buffer and running org-capture
> I obtain an error whose bug trace I attach. Usually I have to restart
> emacs.
>
> ,
> | 
> | Debugger entered--Lisp error: (error "Capture template ‘ms’: No article on 
> current line")
> |   signal(error ("Capture template ‘ms’: No article on current line"))
> |   error("Capture template `%s': %s" "ms" "No article on current line")
> |   org-capture(nil)
> |   funcall-interactively(org-capture nil)
> |   call-interactively(org-capture nil nil)
> |   command-execute(org-capture)

With this backtrace alone (which involves org-capture catching the
internal error), I think it's going to be hard for anyone to guess
what's going on here.  It sounds like once you encounter this error,
subsequent calls reliably trigger it.  Next time you run into it, I'd
suggest re-evaluating org-capture to something like below to hopefully
see a more informative backtrace.

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 831c3e1f4..b20124ced 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -693,9 +693,7 @@ (defun org-capture ( goto keys)
  (string-prefix-p "CAPTURE-" (buffer-name)))
 (kill-buffer (current-buffer)))
   (set-window-configuration (org-capture-get :return-to-wconf))
-  (error "Capture template `%s': %s"
- (org-capture-get :key)
- (error-message-string error
+  (signal (car error) (cdr error
(when (and (derived-mode-p 'org-mode) (org-capture-get :clock-in))
  (condition-case nil
  (progn

Re: List of ob-* maintainers

[Kyle Meyer]

Thomas S. Dye writes:

> Aloha Kyle,
>
> Thanks for this.  I think the Worg list might be useful to 
> indicate which languages don't have maintainers. Or, is the 
> information in the source files sufficient?

I don't know, but adding the information to the Worg table sounds fine
to me.

Thanks.

Re: Bug: table header line mode misaligned in org-indent-mode

[Kyle Meyer]

Oorja Sandhu writes:

> Steps :
> 1. emacs -Q
> Latest Emacs cloned and built from master today.
>
> 2. Open the attached org file
>
> 3. M-x org-table-header-line-mode
>
> 4. M-x org-indent-mode
>
> 5. Resize emacs window very small such that horizontal as well as vertical 
> scrolling is required to see it fully.
>
> 6. Go to end of line in a row in the table when the header line overlay is 
> active.
>
> Observation : the header is misaligned proportional to depth of current 
> headline, attached screenshot.
>
> Expectation : header be indented as much as the table.

Thanks for the report.  I can trigger it, though I haven't been able to
come up with a fix.  It seems like it must be some interaction between
text properties (org-indent-mode) and overlays
(org-table-header-line-mode), but I don't have a good idea of what that
would be.  Perhaps others have ideas.

Re: Bug: wrong font for checkboxes in org-mouse mode org-odt-data-dir not defined correctly [9.4.4 (9.4.4-dist @ /Users/administrator/.emacs.d/packages/elpa/org-plus-contrib-20210322/)]

[Kyle Meyer]

Yaroslav Rogov writes:

> Currenty there’re following lines in org-mouse.el:
>
> (font-lock-add-keywords
>nil
>`(("^[ \t]*\\([-+*]\\|[0-9]+[.)]\\) +\\(\\[[ X]\\]\\)"
>   (2 `(face bold keymap ,org-mouse-map mouse-face highlight) 
> t)))
>t))
>
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-mouse.el#L893-L897
>
> Yet there’s special org-checkbox face obviously not used here.
> Relic from the past?

Thanks for noticing.  It does look like a relic, and org-checkbox should
be used here for a consistent appearance.  Updated (9b4dbe5f0).

What's the "org-odt-data-dir not defined correctly" bit in the subject
about?

Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Kyle Meyer]

Jorge P. de Morais Neto writes:

> Hi.  The HTML export has JavaScript that LibreJS does not recognize as
> free.

Thanks for noting this.  That's certainly not ideal.

> My first attempt at an workaround (inspired by the Org Mode mailing
> list) was merely encoding the ampersand in the magnet link, but that
> *did not make LibreJS happy*.  Then I checked LibreJS manual and saw
> this excerpt:
>
> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1
>
> Public domain is not a license (see
> https://www.gnu.org/licenses/license-list.html#PublicDomain).  If
> you want to release your work to the public domain, the FSF
> recommends using CC0.
>
> Then I came up with a successful workaround.  I included the following
> code in my Org Mode customization file:

Hmm, the public domain switched happen with 471054136 (ox-html.el: Use
classList and put in the public domain, 2020-09-05) and the associated
thread is

  https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/

(+cc author and committer)

> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS
> (with-eval-after-load 'ox-html
>   (setq org-html-scripts
>   (string-replace "\
> // @license 
> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a=public-domain.txt
>  Public Domain"
>   "\
> // @license 
> magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08dn=cc0.txt 
> CC0-1.0"
>   org-html-scripts)))
>
> This works; it makes LibreJS happy.

Okay.  Anthony/Bastien/others, thoughts on using CC0 instead?

Re: List of ob-* maintainers

[Kyle Meyer]

Thomas S. Dye writes:

> Aloha all,
>
> Is there a list of current ob-* maintainers?

Bastien updated the "Maintainer" field of the source files:

  $ git grep -i maintainer lisp/ob-* | cut -d'<' -f1
  lisp/ob-C.el:;; Maintainer: Thierry Banel
  lisp/ob-J.el:;; Maintainer: Joseph Novakovich
  lisp/ob-R.el:;; Maintainer: Jeremie Juste
  lisp/ob-abc.el:;; Maintainer: William Waites
  lisp/ob-clojure.el:;; Maintainer: Bastien Guerry
  lisp/ob-dot.el:;; Maintainer: Justin Abrahms
  lisp/ob-eshell.el:;; Maintainer: stardiviner
  lisp/ob-groovy.el:;; Maintainer: Palak Mathur
  lisp/ob-haskell.el:;; Maintainer: Lawrence Bottorff
  lisp/ob-java.el:;; Maintainer: Ian Martins
  lisp/ob-mscgen.el:;; Maintainer: Justin Abrahms
  lisp/ob-perl.el:;; Maintainer: Corwin Brust
  lisp/ob-python.el:;; Maintainer: Jack Kamm
  lisp/ob-screen.el:;; Maintainer: Ken Mankoff

  $ git describe
  release_9.4.5-317-g3d5284326

The oldest addition is from September 2020, so that should be a fairly
current list.

> Perhaps it would be useful to add and populate a Maintainer column to
> the language table on Worg (org-contrib/babel/languages/index.html)?

Hmm, I suppose it's nice to have just one spot to avoid information
becoming out of sync, but that's a minor issue, so no objections from me
if you or others think it'd be helpful to have the information on Worg.

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Kyle Meyer]

Tim Visher writes:

> On Wed, Jan 20, 2021 at 11:10 PM Kyle Meyer  wrote:
>>
>> It's been applied to master (f4b9f9808).  Please report back if you
>> still encounter the problem in your use case.
>>
>
> I (finally) got around to testing this out. Initially I thought it had been
> released in 9.4.5 but AFAICT that's not the case. Does org not get released
> from `master`?

For version X.Y.Z, Z ticks happen from maint.

> Unfortunately, the title now is essentially the exact text of the org
> heading, which is awkward in terms of readability for a general audience
> (and probably for SEO etc.). I know I said in my original message that I
> think stripping all the markup characters would be going too far but now I
> think I've come full circle and rendering the title as nothing but the
> plain text without any markup information feels like the right solution
> given what the title is supposed to convey.
>
> So, would we be willing to accept a patch to that effect? :)

I don't have an informed opinion about the above, but providing a patch
might prompt those that do (including TEC, the author of the above
commit, as well as Jens, who provided reviews) to give their input.

Re: link syntax fixing bug?

[Kyle Meyer]

Samuel Wales writes:

> in recent maint, i am trying the code included with the maint release
> to update org link escaping syntax.
>
> the issue is that when i click on google, the space before "hi" does
> not show up in the earch box.  ergo, different results.
>
> *** should be orig
> [[http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22][retro
> original]]
> *** should be fixed, is not?
> [[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro
> original]]

My understanding is that the Org 9.3 changes were about moving away from
the percent-encoding that Org used to avoid "[" and "]" in the link.  It
looks like the URL you're showing above should be left as is because it
is the usual URL percent-encoding, without the pre-9.3 Org
percent-encoding on top.

Here are some threads related to this:

  https://orgmode.org/list/87tvguyohn@nicolasgoaziou.fr/T/#u
  https://orgmode.org/list/87sgvusl43@nicolasgoaziou.fr/T/#u

Re: [PATCH] Remove diary-list-entries Emacs 21 compat code

[Kyle Meyer]

Stefan Kangas writes:

> Please find attached a small cleanup patch to org-agenda.el.

Thanks.  Pushed (3a7e1c047).

Re: [PATCH] org-eldoc: Fix compatibility with eldoc 1.11 and Emacs 27

[Kyle Meyer]

Trevor Murphy writes:

> * contrib/lisp/org-eldoc.el (org-eldoc-documentation-function): Check
>   before invoking elisp eldoc functions from Emacs 28.
>
> The previous check assumed that the presence of eldoc 1.11 bindings
> implied elisp-mode bindings that come with Emacs>=28, but eldoc 1.11
> is available on GNU Elpa so the assumption doesn't always hold.

Thanks.  Pushed (7e2eba8cc).

Re: Bug: table header line mode causes next-line to reach beginning of line

[Kyle Meyer]

Oorja Sandhu writes:

[...]
> 3. M-x org-table-header-line-mode
>
> 4. Resize emacs window very small such that horizontal as well as
> vertical scrolling is required to see it fully.
> 
> Otherwise, add rows and columns in the org table in the file such that
> it exceeds window size both vertically and horizontally. This is not a
> useless example because the header line mode is most useful when you
> have a big table and heading scrolls off your visible window.
>
> 5. Go to end of line in a row in the table when the header line
> overlay is active.
>
> 6. Press C-n  (or down arrow) twice
>
> Observation : cursor is at the beginning-of-line
>
> Expected : cursor should remain at the same column as earlier

Thanks for the report and the clear steps to reproduce the issue.

> =
> My unsuccessful code analysis, if anyone is interested :
> There is a post command hook to update the overlay of table
> header. This includes the function "beginning-of-line". In more recent
> versions of org, it is (move-beginning-of-line 2).
>
> But all instances of "beginning-of-line" or "move-beginning-of-line"
> are wrapped in "save-excursion".. In fact if I invoke
> (org-table-header-set-header) instead of C-n, the cursor does not go
> to beginning of line.

Yes, it looks like the issue is that the movement in
org-table-header-set-header resets temporary-goal-column to 0, messing
with the logic in line-move-1.  This should be fixed by f12ca1a56.