Minor patch

[Stefan Monnier]

The minor patch below clarifies what the computation is about and
removes the assumption that point-min == 1, while arguably
making the the code ever so slightly more efficient.


Stefan
>From d386af0653ff75956cc20e0df8ddb5bfa86fec9d Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Wed, 13 Mar 2024 08:31:11 -0400
Subject: [PATCH] (org-src-font-lock-fontify-block): Clarify offset computation

* lisp/org-src.el (org-src-font-lock-fontify-block): Improve the translation
of local positions into org-buffer positions, and get rid of
assumption about the value of `point-min` while we're at it.
---
 lisp/org-src.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index de8d6ee42c..bec13427c2 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -681,7 +681,9 @@ as `org-src-fontify-natively' is non-nil."
 	(unless (eq major-mode lang-mode) (funcall lang-mode))
 (setq native-tab-width tab-width)
 (font-lock-ensure)
-	(let ((pos (point-min)) next)
+	(let ((pos (point-min)) next
+	  ;; Difference between positions here and in org-buffer.
+	  (offset (- start (point-min
 	  (while (setq next (next-property-change pos))
 	;; Handle additional properties from font-lock, so as to
 	;; preserve, e.g., composition.
@@ -695,7 +697,7 @@ as `org-src-fontify-natively' is non-nil."
 (when new-prop
   (if (not (eq prop 'invisible))
 		  (put-text-property
-		   (+ start (1- pos)) (1- (+ start next)) prop new-prop
+		   (+ offset pos) (+ offset next) prop new-prop
 		   org-buffer)
 ;; Special case.  `invisible' text property may
 ;; clash with Org folding.  Do not assign
@@ -727,7 +729,7 @@ as `org-src-fontify-natively' is non-nil."
 (when invisibility-spec
   (add-to-invisibility-spec invisibility-spec))
 (put-text-property
-		 (+ start (1- pos)) (1- (+ start next))
+		 (+ offset pos) (+ offset next)
  'org-src-invisible new-prop
 		 org-buffer)))
 	(setq pos next)))
-- 
2.43.0

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

[Stefan Nobis]

Juan Manuel Macías  writes:

>>> :export "latex+ html+ rest*"

>> "rest" might be a valid backend name.

> I will try to implement the "rest" option.

What about "others" or even ":others" as a placeholder for any not
explicitly mentioned export backend?

Another quick thought crossing my mind: May make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?

-- 
Until the next mail...,
Stefan.

Re: Provide sane default for the @direntry

[Stefan Monnier]

> Thanks!
> Unfortunately, the patch causes some tests (make test) to fail.
> Looks like export to temporary buffer is broken (temporary buffer does
> not have a filename):
>
> 2 unexpected results:
>FAILED  test-ox-texinfo/end-to-end-inline  stringp
>FAILED  test-ox-texinfo/end-to-end-sanity-check-displayed  stringp
[...]
> ^^ stray newline.
[...]
> This is under Org 9.6 header, while should be under Org 9.7 (not yet
> released).

I fixed those three issues (I still get test failures, but I get the
same with or without my patch ).


Stefan
>From 11a40ce47b104609c003c7b9d871db1f2f26be67 Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Tue, 5 Mar 2024 14:11:19 -0500
Subject: [PATCH 1/2] lisp/ox-texinfo.el: Remove redundant `:group`s

---
 lisp/ox-texinfo.el | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index bd01effaa6..d74ed50033 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -147,12 +147,10 @@
   "Default document encoding for Texinfo output.
 
 If nil it will default to `buffer-file-coding-system'."
-  :group 'org-export-texinfo
   :type 'coding-system)
 
 (defcustom org-texinfo-default-class "info"
   "The default Texinfo class."
-  :group 'org-export-texinfo
   :type '(string :tag "Texinfo class"))
 
 (defcustom org-texinfo-classes
@@ -205,7 +203,6 @@ The sectioning structure of the class is given by the elements
 following the header string.  For each sectioning level, a number
 of strings is specified.  A %s formatter is mandatory in each
 section string and will be replaced by the title of the section."
-  :group 'org-export-texinfo
   :version "27.1"
   :package-version '(Org . "9.2")
   :type '(repeat
@@ -233,7 +230,6 @@ TEXT  the main headline text (string).
 TAGS  the tags as a list of strings (list of strings or nil).
 
 The function result will be used in the section format string."
-  :group 'org-export-texinfo
   :type 'function
   :version "26.1"
   :package-version '(Org . "8.3"))
@@ -244,38 +240,32 @@ The function result will be used in the section format string."
   "Column at which to start the description in the node listings.
 If a node title is greater than this length, the description will
 be placed after the end of the title."
-  :group 'org-export-texinfo
   :type 'integer)
 
  Timestamps
 
 (defcustom org-texinfo-active-timestamp-format "@emph{%s}"
   "A printf format string to be applied to active timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-inactive-timestamp-format "@emph{%s}"
   "A printf format string to be applied to inactive timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-diary-timestamp-format "@emph{%s}"
   "A printf format string to be applied to diary timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
  Links
 
 (defcustom org-texinfo-link-with-unknown-path-format "@indicateurl{%s}"
   "Format string for links with unknown path type."
-  :group 'org-export-texinfo
   :type 'string)
 
  Tables
 
 (defcustom org-texinfo-tables-verbatim nil
   "When non-nil, tables are exported verbatim."
-  :group 'org-export-texinfo
   :type 'boolean)
 
 (defcustom org-texinfo-table-scientific-notation nil
@@ -285,7 +275,6 @@ The format should have \"%s\" twice, for mantissa and exponent
 \(i.e. \"%stimes10^{%s}\").
 
 When nil, no transformation is made."
-  :group 'org-export-texinfo
   :type '(choice
 	  (string :tag "Format string")
 	  (const :tag "No formatting" nil)))
@@ -297,7 +286,6 @@ This should an indicating command, e.g., \"@code\", \"@kbd\" or
 \"@samp\".
 
 It can be overridden locally using the \":indic\" attribute."
-  :group 'org-export-texinfo
   :type 'string
   :version "26.1"
   :package-version '(Org . "9.1")
@@ -323,7 +311,6 @@ to typeset and protects special characters.
 
 When no association is found for a given markup, text is returned
 as-is."
-  :group 'org-export-texinfo
   :version "26.1"
   :package-version '(Org . "9.1")
   :type 'alist
@@ -341,7 +328,6 @@ The function must accept two parameters:
 The function should return the string to be exported.
 
 The default function simply returns the value of CONTENTS."
-  :group 'org-export-texinfo
   :version "24.4"
   :package-version '(Org . "8.2")
   :type 'function)
@@ -361,7 +347,6 @@ The function must accept six parameters:
   CONTENTS  the contents of the inlinetask, as a string.
 
 The function should return the string to be exported."
-  :group 'org-export-texinfo
   :type 

Re: Provide sane default for the @direntry

[Stefan Monnier]

> The patches are against Emacs git repository, not against Org mode. May
> your please port them?

See attached.

>> Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s
> By our convention, we drop leading * in the first line of the commit message.

Done.

>> * lisp/org/ox-texinfo.el (texinfo): Add entry for TEXINFO_DIR_NAME.
>> (org-texinfo-template): Use sane defaults for `@direntry` and `@dircategory`.
>> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.
> * etc/ORG-NEWS changelog entry is missing.

Hmm... did know you needed them.

>> +- =TEXINFO_DIR_NAME= ::
>> +
>> +  #+cindex: @samp{TEXINFO_DIR_NAME}, keyword
>> +  The directory name of the document.
>> +  This is the short name under which the ~m~ command will find your
>> +  manual in the main Info directory.  It defaults to the base name of
>> +  the Texinfo file.
>> +
>> +  The full form of the Texinfo entry is ~* DIRNAME: NODE.~ where ~NODE~
>> +  is usually just ~(FILENAME)~.  Normally this option only provides the
>> +  ~DIRNAME~ part, but if you need more control, it can also be the full
>> +  entry (recognized by the presence of parentheses or a leading ~* ~).
>>  
>>  - =TEXINFO_DIR_TITLE= ::
>>  
>>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
>> -  The directory title of the document.
>> +  Old and obsolete name of the =TEXINFO_DIR_NAME= option.
>
> We can simply remove TEXINFO_DIR_TITLE from the manual.

Fair enough.

> Also, please update "Info directory file" section. In particular,
> references to TEXINFO_DIR_TITLE.

Indeed, thanks for spotting this.

>> +(dn (or (plist-get info :texinfo-dirname)
>> +(plist-get info :texinfo-dirtitle))) ;Obsolete name.
>> +;; Strip any terminating `.' from `dn'.
>> +(dn (if (string-match "\\.\\'" dn) (substring dn 0 -1) dn))
>
> `string-match' will throw an error when both :texinfo-dirname and
> :texinfo-dirtitle records are not provided (nil).

Duh!


Stefan
>From ae03b9fa16599eae15a13167d7158266640e76fc Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Tue, 5 Mar 2024 14:11:19 -0500
Subject: [PATCH 1/2] lisp/ox-texinfo.el: Remove redundant `:group`s

---
 lisp/ox-texinfo.el | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index bd01effaa6..ef46dafff2 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -147,12 +147,10 @@
   "Default document encoding for Texinfo output.
 
 If nil it will default to `buffer-file-coding-system'."
-  :group 'org-export-texinfo
   :type 'coding-system)
 
 (defcustom org-texinfo-default-class "info"
   "The default Texinfo class."
-  :group 'org-export-texinfo
   :type '(string :tag "Texinfo class"))
 
 (defcustom org-texinfo-classes
@@ -205,7 +203,6 @@ The sectioning structure of the class is given by the elements
 following the header string.  For each sectioning level, a number
 of strings is specified.  A %s formatter is mandatory in each
 section string and will be replaced by the title of the section."
-  :group 'org-export-texinfo
   :version "27.1"
   :package-version '(Org . "9.2")
   :type '(repeat
@@ -233,7 +230,6 @@ TEXT  the main headline text (string).
 TAGS  the tags as a list of strings (list of strings or nil).
 
 The function result will be used in the section format string."
-  :group 'org-export-texinfo
   :type 'function
   :version "26.1"
   :package-version '(Org . "8.3"))
@@ -244,38 +240,32 @@ The function result will be used in the section format string."
   "Column at which to start the description in the node listings.
 If a node title is greater than this length, the description will
 be placed after the end of the title."
-  :group 'org-export-texinfo
   :type 'integer)
 
  Timestamps
 
 (defcustom org-texinfo-active-timestamp-format "@emph{%s}"
   "A printf format string to be applied to active timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-inactive-timestamp-format "@emph{%s}"
   "A printf format string to be applied to inactive timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-diary-timestamp-format "@emph{%s}"
   "A printf format string to be applied to diary timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
  Links
 
 (defcustom org-texinfo-link-with-unknown-path-format "@indicateurl{%s}"
   "Format string for links with unknown path type."
-  :group 'org-export-texinfo
   :type 'string)
 
  Tables
 
 (defcustom org-texinfo-tables-verbatim nil
   &qu

Re: Provide sane default for the @direntry

[Stefan Monnier]

New version of the patch, which I believe address your comments.


Stefan
>From 53c8fab18625e8a722657181cb3c825a1d8c895c Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Tue, 5 Mar 2024 14:11:19 -0500
Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s

---
 lisp/org/ox-texinfo.el | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/lisp/org/ox-texinfo.el b/lisp/org/ox-texinfo.el
index 84313645e6e..b3b94511d50 100644
--- a/lisp/org/ox-texinfo.el
+++ b/lisp/org/ox-texinfo.el
@@ -147,12 +147,10 @@ org-texinfo-coding-system
   "Default document encoding for Texinfo output.
 
 If nil it will default to `buffer-file-coding-system'."
-  :group 'org-export-texinfo
   :type 'coding-system)
 
 (defcustom org-texinfo-default-class "info"
   "The default Texinfo class."
-  :group 'org-export-texinfo
   :type '(string :tag "Texinfo class"))
 
 (defcustom org-texinfo-classes
@@ -205,7 +203,6 @@ org-texinfo-classes
 following the header string.  For each sectioning level, a number
 of strings is specified.  A %s formatter is mandatory in each
 section string and will be replaced by the title of the section."
-  :group 'org-export-texinfo
   :version "27.1"
   :package-version '(Org . "9.2")
   :type '(repeat
@@ -233,7 +230,6 @@ org-texinfo-format-headline-function
 TAGS  the tags as a list of strings (list of strings or nil).
 
 The function result will be used in the section format string."
-  :group 'org-export-texinfo
   :type 'function
   :version "26.1"
   :package-version '(Org . "8.3"))
@@ -244,38 +240,32 @@ org-texinfo-node-description-column
   "Column at which to start the description in the node listings.
 If a node title is greater than this length, the description will
 be placed after the end of the title."
-  :group 'org-export-texinfo
   :type 'integer)
 
  Timestamps
 
 (defcustom org-texinfo-active-timestamp-format "@emph{%s}"
   "A printf format string to be applied to active timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-inactive-timestamp-format "@emph{%s}"
   "A printf format string to be applied to inactive timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-diary-timestamp-format "@emph{%s}"
   "A printf format string to be applied to diary timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
  Links
 
 (defcustom org-texinfo-link-with-unknown-path-format "@indicateurl{%s}"
   "Format string for links with unknown path type."
-  :group 'org-export-texinfo
   :type 'string)
 
  Tables
 
 (defcustom org-texinfo-tables-verbatim nil
   "When non-nil, tables are exported verbatim."
-  :group 'org-export-texinfo
   :type 'boolean)
 
 (defcustom org-texinfo-table-scientific-notation nil
@@ -285,7 +275,6 @@ org-texinfo-table-scientific-notation
 \(i.e. \"%stimes10^{%s}\").
 
 When nil, no transformation is made."
-  :group 'org-export-texinfo
   :type '(choice
 	  (string :tag "Format string")
 	  (const :tag "No formatting" nil)))
@@ -297,7 +286,6 @@ org-texinfo-table-default-markup
 \"@samp\".
 
 It can be overridden locally using the \":indic\" attribute."
-  :group 'org-export-texinfo
   :type 'string
   :version "26.1"
   :package-version '(Org . "9.1")
@@ -323,7 +311,6 @@ org-texinfo-text-markup-alist
 
 When no association is found for a given markup, text is returned
 as-is."
-  :group 'org-export-texinfo
   :version "26.1"
   :package-version '(Org . "9.1")
   :type 'alist
@@ -341,7 +328,6 @@ org-texinfo-format-drawer-function
 The function should return the string to be exported.
 
 The default function simply returns the value of CONTENTS."
-  :group 'org-export-texinfo
   :version "24.4"
   :package-version '(Org . "8.2")
   :type 'function)
@@ -361,7 +347,6 @@ org-texinfo-format-inlinetask-function
   CONTENTS  the contents of the inlinetask, as a string.
 
 The function should return the string to be exported."
-  :group 'org-export-texinfo
   :type 'function)
 
  LaTeX
@@ -374,7 +359,6 @@ org-texinfo-with-latex
 respectively.  Alternatively, when set to `detect', the exporter
 does so only if the installed version of Texinfo supports the
 necessary commands."
-  :group 'org-export-texinfo
   :package-version '(Org . "9.6")
   :type '(choice
   (const :tag "Detect" detect)
@@ -391,7 +375,6 @@ org-texinfo-compact-itemx
 transcoded to `@itemx'.  See info node `(org)Plain lists in
 Texinfo export' for how to enable this for individual lists."
   :package-version '(Org . "9.6")
-  :group 'org-export-texinfo
   :type 'boolean
   :safe t)
 

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Stefan]

Hi,

since this patch was applied, there are now two functions in 
`org-store-link-functions` that feel responsible for id links from some 
buffers: the new `org-id-store-link-maybe` and `org-contacts-link-store`.

This results in a prompt asking which one to use, which happens many times, 
e.g., when exporting agendas with org-contacts stuff in them.

Not sure how to improve/avoid that, though. 

Best,
 Stefan

Re: Provide sane default for the @direntry

[Stefan Monnier]

>> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.
> It would be nice to provide etc/ORG-NEWS entry as well.

Yes, thanks.

>>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
>>The directory title of the document.
>> +  This is the short name under which the ~m~ command will find your
>> +  manual in the main Info directory.  It defaults to the base name of
>> +  the Texinfo file.
>> +
>> +  If you need more control, it can also be the full entry using the
>> +  syntax ~* TITLE: (FILENAME).~.
>
> This example is a bit confusing. How will it look like in Org document?
> #+TEXINFO_DIR_TITLE: * title: (filename). ?
> If yes, it is confusing because you just mention that default value is
> filename, but you have both "title" and "filename" in the example.
>
> Maybe
>
> : #+TEXINFO_DIR_TITLE: * name: (filename).
>
> ?

[ Calling it "TITLE" is definitely confusing, I should use DIRTITLE.  ]

And yes, the Texinfo syntax is either

* FILENAME.

or

* DIRTITLE: (FILENAME).

[ where FILENAME which should be the file name without the
  `.info` extension).  ]

so I think it makes a lot sense for DIRTITLE to default to FILENAME?

The "* DIRTITLE: (FILENAME)." syntax is Texinfo's syntax, and currently the
Org user needs to know that syntax and abide by it (even though it's
not well defined nor well documented, IME).  My change mostly makes it
unnecessary for the user to know that syntax because ox-texinfo already
knows the FILENAME, so it only needs the DIRTITLE.

The new code supports the "* DIRTITLE: (FILENAME)." syntax mostly for
backward compatibility, tho it can also be useful in corner cases such
as when the final filename will be different than the one ox-texinfo
knows about.

Not sure how to adjust the text to clarify that, without including
a discussion of the "* DIRTITLE: (FILENAME)." and how things used to be,
and how the filename is controlled.

The old(current) situation is arguably worse because it doesn't even
document the syntax that needs to be used.

>>  - =TEXINFO_DIR_DESC= ::
>>  
>>#+cindex: @samp{TEXINFO_DIR_DESC}, keyword
>>The directory description of the document.
>> +  Defaults to the title of the document.
>
> I'd also add that it should be a short sentence.

Not sure if it needs to be a sentence, but yes, it should usually be
short tho I don't think there's a technical need for it, so I think the
"defaults to the title" should be a good enough hint about the kind of
length expected.

>>  (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
>> +;; FIXME: The naming of these options is unsatisfactory:
>> +;; TEXINFO_DIR_DESC corresponds (and defaults) to the document's
>> +;; title, whereas TEXINFO_DIR_TITLE corresponds (and defaults) to
>> +;; its filename.
> What about TEXINFO_DIR_NAME + TECINFO_DIR_DESC?

Fine by me, yes.

> I do not see a big problem with description defaulting to document title
> given that it should be a short sentence - an equivalent of proper
> document title.

I don't see a problem with it either.  The problem is mostly in the
DIR_TITLE name suggesting it should be like the title rather than the
indexing keyword that it is.

>> + (let* ((dircat (plist-get info :texinfo-dircat))
>> +(dt (plist-get info :texinfo-dirtitle))
>> +(file (file-name-sans-extension
>> +   (or (org-strip-quotes (plist-get info :texinfo-filename))
>> +   (plist-get info :output-file
>> +(dirtitle
>> + (cond
>> +  ((and dt
>> +(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
>> +(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
>> +   ;; `dt' is already "complete".
>> +   (format "* %s." (match-string 1 dt)))
>> +      ((and dt (not (equal dt file)))
>> +   (format "* %s: (%s)." dt file))
>
> It would be nice to add a comment saying that dt values like
> "Foo (filename)" are already captured by the previous cond clause.

I don't understand what you mean by that.

>> +  (t (format "* %s." file)
>
> What if dt is "Foo."?

Good point.


Stefan

Re: Provide sane default for the @direntry

[Stefan Monnier]

> May you please supply a ChangeLog entry? I am not sure if I understand
> the purpose of each change in the diff.
>
> Also, it looks like you introduce some DWIM behaviour for auto-generating
> @direntry contents. Such new behaviour ought to be documented in the
> manual and announced in the news.

New patch attached,


Stefan
>From 6cb66a8737adc8efdb053bd76607289dc120d60b Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Sat, 2 Mar 2024 14:48:29 -0500
Subject: [PATCH] ox-texinfo:: Require only TEXINFO_DIR_CATEGORY

Until now @dircategory/@direntry entries were added only if
both TEXINFO_DIR_CATEGORY and TEXINFO_DIR_TITLE were set.
And the setting of TEXINFO_DIR_TITLE had to be careful to
provide exactly the right syntax.

This patch changes various things in this regard:
- Only require TEXINFO_DIR_CATEGORY in order to generate
  `@dircategory` and `@direntry`.
- Use the document title by default if TEXINFO_DIR_DESC is missing.
- Use the filename by default when TEXINFO_DIR_TITLE is missing.
- Try and make it harder to provide a direntry that does not
  have the right format or refers to a different filename than
  the one we're outputting to.

* lisp/org/ox-texinfo.el: Remove redundant `:group` arguments.
Prefer #' to quote function names.
(org-texinfo-template): Use sane defaults for `@direntry`.

* doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.
---
 doc/misc/org.org   | 11 ++--
 lisp/org/ox-texinfo.el | 58 --
 2 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/doc/misc/org.org b/doc/misc/org.org
index 05ab5b36ca0..f4590525892 100644
--- a/doc/misc/org.org
+++ b/doc/misc/org.org
@@ -15322,11 +15322,18 @@ the general options (see [[*Export Settings]]).
 
   #+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
   The directory title of the document.
+  This is the short name under which the ~m~ command will find your
+  manual in the main Info directory.  It defaults to the base name of
+  the Texinfo file.
+
+  If you need more control, it can also be the full entry using the
+  syntax ~* TITLE: (FILENAME).~.
 
 - =TEXINFO_DIR_DESC= ::
 
   #+cindex: @samp{TEXINFO_DIR_DESC}, keyword
   The directory description of the document.
+  Defaults to the title of the document.
 
 - =TEXINFO_PRINTED_TITLE= ::
 
@@ -15422,7 +15429,7 @@ Here is an example that writes to the Info directory file:
 
 #+begin_example
 ,#+TEXINFO_DIR_CATEGORY: Emacs
-,#+TEXINFO_DIR_TITLE: Org Mode: (org)
+,#+TEXINFO_DIR_TITLE: Org Mode
 ,#+TEXINFO_DIR_DESC: Outline-based notes management and organizer
 #+end_example
 
@@ -15830,7 +15837,7 @@ Texinfo code.
 ,#+TEXINFO_HEADER: @syncodeindex pg cp
 
 ,#+TEXINFO_DIR_CATEGORY: Texinfo documentation system
-,#+TEXINFO_DIR_TITLE: sample: (sample)
+,#+TEXINFO_DIR_TITLE: sample
 ,#+TEXINFO_DIR_DESC: Invoking sample
 
 ,#+TEXINFO_PRINTED_TITLE: GNU Sample
diff --git a/lisp/org/ox-texinfo.el b/lisp/org/ox-texinfo.el
index 84313645e6e..5065c3fb63c 100644
--- a/lisp/org/ox-texinfo.el
+++ b/lisp/org/ox-texinfo.el
@@ -110,6 +110,10 @@ 'texinfo
 (:subtitle "SUBTITLE" nil nil parse)
 (:subauthor "SUBAUTHOR" nil nil newline)
 (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
+;; FIXME: The naming of these options is unsatisfactory:
+;; TEXINFO_DIR_DESC corresponds (and defaults) to the document's
+;; title, whereas TEXINFO_DIR_TITLE corresponds (and defaults) to
+;; its filename.
 (:texinfo-dirtitle "TEXINFO_DIR_TITLE" nil nil t)
 (:texinfo-dirdesc "TEXINFO_DIR_DESC" nil nil t)
 (:texinfo-printed-title "TEXINFO_PRINTED_TITLE" nil nil t)
@@ -147,12 +151,10 @@ org-texinfo-coding-system
   "Default document encoding for Texinfo output.
 
 If nil it will default to `buffer-file-coding-system'."
-  :group 'org-export-texinfo
   :type 'coding-system)
 
 (defcustom org-texinfo-default-class "info"
   "The default Texinfo class."
-  :group 'org-export-texinfo
   :type '(string :tag "Texinfo class"))
 
 (defcustom org-texinfo-classes
@@ -205,7 +207,6 @@ org-texinfo-classes
 following the header string.  For each sectioning level, a number
 of strings is specified.  A %s formatter is mandatory in each
 section string and will be replaced by the title of the section."
-  :group 'org-export-texinfo
   :version "27.1"
   :package-version '(Org . "9.2")
   :type '(repeat
@@ -233,7 +234,6 @@ org-texinfo-format-headline-function
 TAGS  the tags as a list of strings (list of strings or nil).
 
 The function result will be used in the section format string."
-  :group 'org-export-texinfo
   :type 'function
   :version "26.1"
   :package-version '(Org . "8.3"))
@@ -244,38 +244,32 @@ org-texinfo-node-description-column
   "Column at which to start the description in the node listings.
 If a node title is greater tha

Re: Experimental public branch for inline special blocks

[Stefan Nobis]

Hi Juan,

first of all: Thank you for your great work. Looks really good.

Just out of curiosity: Why a special syntax for alias expansion?

>From a syntax and user point of view, I think I would prefer a simpler
syntax. So

{text}

would check if an alias is registered and if yes use it. This way it
would be easier to change/add options later on without the need for
changing all the inline-block commands and add a "!" (not a big deal,
just two rather simple replace commands).

But even as it is it's a very nice and welcome extension (at least to
me)!

-- 
Until the next mail...,
Stefan.

Provide sane default for the @direntry

[Stefan Monnier]

When exporting to Texinfo, the patch below makes it easier to generate
a good `@direntry` by using sane defaults.
For most files, you'll just need

#+TEXINFO_DIR_CATEGORY: {my-category}

I believe it also makes it a bit harder to shoot oneself in the foot and
generate an invalid entry (e.g. with a missing or wrong file name).


Stefan
diff --git a/lisp/org/ox-texinfo.el b/lisp/org/ox-texinfo.el
index 84313645e6e..beea7aacab7 100644
--- a/lisp/org/ox-texinfo.el
+++ b/lisp/org/ox-texinfo.el
@@ -817,17 +799,27 @@ org-texinfo-template
 		   (org-export-data copying info
  ;; Info directory information.  Only supply if both title and
  ;; category are provided.
- (let ((dircat (plist-get info :texinfo-dircat))
-	   (dirtitle
-	(let ((title (plist-get info :texinfo-dirtitle)))
-	  (and title
-		   (string-match "^\\(?:\\* \\)?\\(.*?\\)\\(\\.\\)?$" title)
-		   (format "* %s." (match-string 1 title))
-   (when (and dircat dirtitle)
+ (let* ((dircat (plist-get info :texinfo-dircat))
+	(dt (plist-get info :texinfo-dirtitle))
+	(file (file-name-sans-extension
+		   (or (org-strip-quotes (plist-get info :texinfo-filename))
+		   (plist-get info :output-file
+	(dirtitle
+ (cond
+  ((and dt
+(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
+(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
+   ;; `dt' is already "complete".
+   (format "* %s." (match-string 1 dt)))
+  ((and dt (not (equal dt file)))
+   (format "* %s: (%s)." dt file))
+  (t (format "* %s." file)
+   (when dircat
 	 (concat "@dircategory " dircat "\n"
 		 "@direntry\n"
 		 (let ((dirdesc
-			(let ((desc (plist-get info :texinfo-dirdesc)))
+			(let ((desc (or (plist-get info :texinfo-dirdesc)
+			title)))
 			  (cond ((not desc) nil)
 ((string-suffix-p "." desc) desc)
 (t (concat desc "."))
@@ -1590,7 +1582,7 @@ org-texinfo-planning
   (concat
"@noindent"
(mapconcat
-'identity
+#'identity
 (delq nil
 	  (list
 	   (let ((closed (org-element-property :closed planning)))

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Stefan Kangas]

Adam Porter  writes:

> Since transient.el is part of Emacs now, these kinds of menus should
> probably be implemented with it.

IIUC, this is not a menu, but a reminder of key bindings that are usable
in that context.  Other keybindings here are self-inserting keys, which
are equally useful, and they wouldn't be available in a transient.

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Max Nikulin  writes:

> On 01/02/2024 03:00, Stefan Kangas wrote:
>> Max Nikulin writes:
>>> +++ b/lisp/net/mailcap.el
>>> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>>>   (".jpe"   . "image/jpeg")
>>>   (".jpeg"  . "image/jpeg")
>>>   (".webp"  . "image/webp")
>>> -(".org"   . "text/x-org"))
>>> +;; May be overridden by application/vnd.lotus-organizer in 
>>> /etc/mime.types.
>>> +(".org"   . "text/org"))
>
> Org files are plain text files and have no specific signature that would
> allow tools like libmagic to unambiguously distinguish them from other
> text files. Rare files have explicit "# -*- mode: org-mode -*-" header.
> So there is no other way besides file name extensions when a message is
> composed or a file is served by a HTTP server. Clients should rely on
> the Content-Type header.

So old mailers will still use "Content-Type: text/x-org", and it is
therefore premature to remove that entry.

I'm not sure about the urgency in starting to send out "text/org" at
this stage.  It will just lead to old versions of Emacs displaying org
attachments incorrectly in more cases, I think?

So why not:

 1. Add support for _receiving_ "text/org" in Emacs 30
 2. Wait with _sending_ "text/org" until it is formally accepted by IANA

?

In Emacs <29, perhaps Org mode could update the relevant variables to
include "text/org", too?

>> Is it
>> documented somewhere how to override that system configuration in Emacs?
>
> Create ~/.mime.types. Debian's variant suggests it in the
> /etc/mime.types header.

Is that documented somewhere in our documentation?

>> But thinking about this more, why not do that unconditionally for users?
>> Lotus Organizer is dead, long gone, and not really relevant to anyone,
>> certainly not to the overwhelming majority of Emacs users.
>
> Ideally text/org should be registered in IANA, so all applications could
> use consistent mapping. Prerequisites have been discussed already.

Yes, that would be best.  While waiting for that to happen, why not do
what I proposed (override it unconditionally in Emacs)?  It should be
more useful for Emacs users, if nothing else.

Taking a step back, how sure are we that IANA will accept this?  Do they
typically accept taking over a previous designation?

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Max Nikulin  writes:

> From 8b71393625f11590e99896808bbd04ed83f7917e Mon Sep 17 00:00:00 2001
> From: Max Nikulin 
> Date: Wed, 24 Jan 2024 21:16:28 +0700
> Subject: [PATCH] Use text/org media type
>
> Avoid "x-" prefix deprecated by rfc6648 for Org mode media type.
> * lisp/net/mailcap.el (mailcap-mime-extensions):
> * lisp/gnus/mm-uu.el (mm-uu-org-src-code-block-extract): Replace
> text/x-org by text/org.
> * lisp/gnus/mm-decode.el (mm-inline-media-tests): Allow text/org in
> addition to text/x-org.
>
> Make media type defined for Org mode consistent with
> 
>
> See emacs-orgmode: Org mode MIME type. Sun, 21 Jan 2024 20:56:15 +0700.
> https://list.orgmode.org/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com
> ---
>  lisp/gnus/mm-decode.el | 1 +
>  lisp/gnus/mm-uu.el | 2 +-
>  lisp/net/mailcap.el| 3 ++-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/gnus/mm-decode.el b/lisp/gnus/mm-decode.el
> index f91755e967b..cae737e5a3e 100644
> --- a/lisp/gnus/mm-decode.el
> +++ b/lisp/gnus/mm-decode.el
> @@ -246,6 +246,7 @@ (defcustom mm-inline-media-tests
>  ("text/x-sh" mm-display-shell-script-inline identity)
>  ("application/javascript" mm-display-javascript-inline identity)
>  ("text/dns" mm-display-dns-inline identity)
> +("text/org" mm-display-org-inline identity)
>  ("text/x-org" mm-display-org-inline identity)
>  ("text/html"
>   mm-inline-text-html
> diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
> index 3c7e3cbdf1a..b10da0c143a 100644
> --- a/lisp/gnus/mm-uu.el
> +++ b/lisp/gnus/mm-uu.el
> @@ -394,7 +394,7 @@ (defun mm-uu-emacs-sources-extract ()
>
>  (defun mm-uu-org-src-code-block-extract ()
>(mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
> -   '("text/x-org" (charset . gnus-decoded
> +   '("text/org" (charset . gnus-decoded
>
>  (defvar gnus-newsgroup-name)
>
> diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> index 5ff75deb4e6..900099433c4 100644
> --- a/lisp/net/mailcap.el
> +++ b/lisp/net/mailcap.el
> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>  (".jpe"   . "image/jpeg")
>  (".jpeg"  . "image/jpeg")
>  (".webp"  . "image/webp")
> -(".org"   . "text/x-org"))
> +;; May be overridden by application/vnd.lotus-organizer in 
> /etc/mime.types.
> +(".org"   . "text/org"))

It's been many moons since I last looked at email attachements in any
detail, so I have some questions.

With this patch, what happens if someone is emailing using an old
version of Emacs?  Does that matter, or is this stuff based only on the
file ending?  IOW, I'm asking if it is backwards-compatible to remove
"text/org", in either direction.  Will .org files be displayed in the
same way as before or not on both new and old versions?

I've noticed on my machine that .org files have been interpreted as
application/vnd.lotus-organizer.  Presumably that's due to some local
configuration in /etc/mime.types on my distro.  Is that correct?  Is it
documented somewhere how to override that system configuration in Emacs?

But thinking about this more, why not do that unconditionally for users?
Lotus Organizer is dead, long gone, and not really relevant to anyone,
certainly not to the overwhelming majority of Emacs users.  On the off
chance that someone is opening such files from Emacs, they could just
revert that locally.  WDYT?

>"An alist of file extensions and corresponding MIME content-types.
>  This exists for you to customize the information in Lisp.  It is
>  merged with values from mailcap files by `mailcap-parse-mimetypes'.")
> --
> 2.39.2

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Ihor Radchenko  writes:

> I see using text/org as an improvement. text/x-org is likely useless.
> At least,
> https://github.com/jeremy-compostella/org-msg/blob/master/org-msg.el
> uses text/org, which may appear in email parts.
>
> However, AFAIU, text/org will fall into "standards tree" in IANA media
> type specification, which means that it MUST be registered, as described
> in https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1
>
> Registering text/org media type requires syntax spec. We are
> still working on format Org mode syntax specifications. See
> https://list.orgmode.org/orgmode/871rjhha8t@gmail.com/ and
> https://orgmode.org/worg/org-syntax.html
>
> The spec is still not fully finalized, so we are not yet initiating the
> registration, as we will need to repeat it again if we decide to make
> further changes (https://www.rfc-editor.org/rfc/rfc6838.html#section-5.5)

What does this mean with regards to the patch?  Should we wait with
installing it until that process is done?

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Max Nikulin  writes:

> Hi,
>
> I suggest to make the media type used for Org mode files consistent with
> the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
> Currently Emacs has text/x-org, however "x-" prefix is not recommended
> by IANA any more, see https://www.rfc-editor.org/rfc/rfc6648
> "Deprecating the "X-" Prefix and Similar Constructs in Application
> Protocols"
>
> Ideally somebody should file a request to IANA to register the text/org
> media type.
> https://www.iana.org/assignments/media-types/media-types.xhtml

Eli, Ihor, what do you think?

> However I have no idea concerning a conflict due to the .org file name
> suffix. It was used in the past by early versions of Lotus Organizer.
> https://www.iana.org/assignments/media-types/application/vnd.lotus-organizer
>
> I am unsure if gnus-related code should be committed to some other
> repository at first. I am not a gnus user, so I do not mind if an
> alternative change will be committed.
>
> See also
> emacs-orgmode: Org mode MIME type. Sun, 21 Jan 2024 20:56:15 +0700.
> https://list.orgmode.org/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com
> From 8b71393625f11590e99896808bbd04ed83f7917e Mon Sep 17 00:00:00 2001
> From: Max Nikulin 
> Date: Wed, 24 Jan 2024 21:16:28 +0700
> Subject: [PATCH] Use text/org media type
>
> Avoid "x-" prefix deprecated by rfc6648 for Org mode media type.
> * lisp/net/mailcap.el (mailcap-mime-extensions):
> * lisp/gnus/mm-uu.el (mm-uu-org-src-code-block-extract): Replace
> text/x-org by text/org.
> * lisp/gnus/mm-decode.el (mm-inline-media-tests): Allow text/org in
> addition to text/x-org.
>
> Make media type defined for Org mode consistent with
> 
>
> See emacs-orgmode: Org mode MIME type. Sun, 21 Jan 2024 20:56:15 +0700.
> https://list.orgmode.org/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com
> ---
>  lisp/gnus/mm-decode.el | 1 +
>  lisp/gnus/mm-uu.el | 2 +-
>  lisp/net/mailcap.el| 3 ++-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/gnus/mm-decode.el b/lisp/gnus/mm-decode.el
> index f91755e967b..cae737e5a3e 100644
> --- a/lisp/gnus/mm-decode.el
> +++ b/lisp/gnus/mm-decode.el
> @@ -246,6 +246,7 @@ (defcustom mm-inline-media-tests
>  ("text/x-sh" mm-display-shell-script-inline identity)
>  ("application/javascript" mm-display-javascript-inline identity)
>  ("text/dns" mm-display-dns-inline identity)
> +("text/org" mm-display-org-inline identity)
>  ("text/x-org" mm-display-org-inline identity)
>  ("text/html"
>   mm-inline-text-html
> diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
> index 3c7e3cbdf1a..b10da0c143a 100644
> --- a/lisp/gnus/mm-uu.el
> +++ b/lisp/gnus/mm-uu.el
> @@ -394,7 +394,7 @@ (defun mm-uu-emacs-sources-extract ()
>
>  (defun mm-uu-org-src-code-block-extract ()
>(mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
> -   '("text/x-org" (charset . gnus-decoded
> +   '("text/org" (charset . gnus-decoded
>
>  (defvar gnus-newsgroup-name)
>
> diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> index 5ff75deb4e6..900099433c4 100644
> --- a/lisp/net/mailcap.el
> +++ b/lisp/net/mailcap.el
> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>  (".jpe"   . "image/jpeg")
>  (".jpeg"  . "image/jpeg")
>  (".webp"  . "image/webp")
> -(".org"   . "text/x-org"))
> +;; May be overridden by application/vnd.lotus-organizer in 
> /etc/mime.types.
> +(".org"   . "text/org"))
>"An alist of file extensions and corresponding MIME content-types.
>  This exists for you to customize the information in Lisp.  It is
>  merged with values from mailcap files by `mailcap-parse-mimetypes'.")
> --
> 2.39.2

Re: org-publish-sitemap-file-entry-format documented despite being obsolete

[Stefan Kangas]

Ihor Radchenko  writes:

> Stefan Kangas  writes:
>
>> The variable `org-publish-sitemap-file-entry-format' is documented in
>> org.org in emacs.git, but that variable is obsolete.  Perhaps it should
>> be removed and/or updated.
>
> My grepping through Emacs sources does not show anything:
>
> 3 matches total for "org-publish-sitemap-file-entry-format":
> 2 matches in buffer: org-compat.el
> 762:(defcustom org-publish-sitemap-file-entry-format "%t"
> 772: 'org-publish-sitemap-file-entry-format
> 1 match in buffer: ORG-NEWS
>4056:*** ~org-publish-sitemap-file-entry-format~ is deprecated

Thanks, I must have grepped the wrong directory.  Sorry for the noise.

BTW, I see the following symbols that are only mentioned once in
emacs.git, so I suspect some of them might be typos.

I fixed a few typos on master in emacs.git already (9364c28959a):

org-col-cookies
org-export--populate-ignore-list
org-latex--org-align-string-tabbing
org-publish-sitemap-date-format
org-table-hide-column
org-table-increment
org-translate-link-from-planner
org-try-structure-completion

org-publish-sitemap-file-entry-format documented despite being obsolete

[Stefan Kangas]

The variable `org-publish-sitemap-file-entry-format' is documented in
org.org in emacs.git, but that variable is obsolete.  Perhaps it should
be removed and/or updated.

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

> (setq-local kill-line-query-function #'org-kill-line-query)

Please use `add-function` for such things.
That's its raison d'être.


    Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

>> I said that remapping widely-used keys to commands that behave
>> significantly differently places a non-trivial burden on users,
>> especially on those who use the remapping mode relatively rarely.
>
> Sure. From which I concluded that Org mode should avoid remapping

I don't think that's what it means.  It means that it depends on what is
the end-user-visible effect.  If the remapped version of the command
"does the same" conceptually, then it's OK (even more so if the
non-remapped version of the command ends up misbehaving).

I think the main question is: can we expect that some users out there
will want to use the non-remapped version of the command because they
prefer its behavior?

So, when the alternative is to directly modify the behavior of the
non-remapped command, remapping is always acceptable.
[ But sometimes, remapping just doesn't do what we want, because the
  command is also used as a function from other places.  ]


Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

> Eli told me in the past that Org mode should not remap keys.
> See the discussion branch starting at
> https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/

Then I'll let Eli take care of this :-)


    Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

>> That's why I said "rule of thumb": there can be tradeoffs.
>> In practice 99% of Emacs commands modify only a single contiguous chunk
>> of text, so the tradeoff comes into play fairly rarely.
> It would be nice if this advice were added to the relevant docstrings.

Not sure exactly which advice you're referring to (the text you quoted
above is misleading: it would encourage the naive reader to just do the
work in `after-change-functions` since it's called only once per command
anyway, which they already instinctively do and which is exactly what we
don't want), nor which docstring you're referring to.


Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

>>> But in addition to that, I suspect that Org should probably not modify
>>> visibility directly from the modification hooks.  Instead, its
>>> modification hook function should just stash the info somewhere and then
>>> update the visibility later on, such as in a `post-command-hook`, timer,
>>> `pre-redisplay-functions`, younameit.
>> Good idea. At least, for this specific feature in Org mode.
> Now, done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f9702a09e

Great, thanks!

> Although, I am still interested to pursue feature request to allow
> customizing `kill-whole-line' and `kill-line' by major modes.

[ I'm sorry I didn't pay very much attention to this part.
  Naively, I'd suggest you use `remap` bindings for that, but I'm sure
  you're aware of that option, so you presumably have good reasons to
  want something else.  ]


Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

>> As a rule of thumb, I think modification hooks should be treated a bit
>> like POSIX signal handlers: just record the event somewhere but don't do
>> any substantial work in there.
> Yet, it is sometimes necessary to modify text right inside the
> modification hooks. Otherwise, it is very hard (and sometimes
> impossible) to keep track of the original text region when multiple
> modifications happen there one by one.

It's always "possible", but yes there can be undesirable effects:
usually as you delay the updates you're forced to reduce the granularity
of the recorded changes, so in you may end up treating a series of small
changes as one big-ass change for which your updates may not be able to
do as good a job.

E.g. in `diff-mode` we try to allow editing the patch, and dynamically
update the hunk headers accordingly.  This works well for an edit within
a single hunk but doing it for larger edits is somewhere between hard
and undesirable so we don't do it.

If a command changes just two lines but in two different hunks, our code
treats it a a single change that spans two hunks and thus refrains from
updating the hunk headers, as if the command had actually deleted and
then reinserted all the text between those two lines.

That's why I said "rule of thumb": there can be tradeoffs.
In practice 99% of Emacs commands modify only a single contiguous chunk
of text, so the tradeoff comes into play fairly rarely.


Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Stefan Monnier]

> The reported bug is a side effect of a feature when Org automatically
> reveals hidden outlines that are "broken" due to edits and thus could
> not be unfolded easily. For example, when destroying parent heading in a
> folding subtree:

I'd be in favor of changing `kill-whole-line` to do the kill in a single
step rather than killing the "before" and "after" separately.
I understand why it doesn't do that, but I'm not sure it's worth the
trouble (or we should change the `kill-region` thingy to be more
robust, e.g. record the position of the last kill so that it doesn't
need to rely on (< end beg) to guess whether to append or prepend and
it can automatically notice when the new kill is *around* the previous
one).

But in addition to that, I suspect that Org should probably not modify
visibility directly from the modification hooks.  Instead, its
modification hook function should just stash the info somewhere and then
update the visibility later on, such as in a `post-command-hook`, timer,
`pre-redisplay-functions`, younameit.

As a rule of thumb, I think modification hooks should be treated a bit
like POSIX signal handlers: just record the event somewhere but don't do
any substantial work in there.


Stefan

Re: [DISCUSSION] Possible inclusion of org-capture.el into Emacs core (was: [ELPA] New package: jami-bot and org-jami-bot)

[Stefan Kangas]

Ihor Radchenko  writes:

> With org-protocol, one can also make Emacs receive data from browser and
> perform any action defined by custom handler function - all fully
> configurable and not necessarily related to Org mode.

I don't have much to add besides giving support to the idea.  It would
be useful.  I'm sure it would find its use in other types of note taking
and productivity systems, of which we have several.

Re: [DISCUSSION] org-capture.el vs remember.el (was: [ELPA] New package: jami-bot and org-jami-bot)

[Stefan Kangas]

Ihor Radchenko  writes:

> The refactoring de-coupled what used to be org-remember.el into
> completely rewritten org-capture.el that added important features that
> could not be implemented within remember.el framework:
>
> 1. org-capture arranges writing the text to remember directly into the
>target location where it is to be stored. This addressed an important
>problem of remember.el - remember.el always uses temporary buffer for
>user input and does not save it until remember-finalize is executed
>explicitly. A number of users sometimes forgot to call
>remember-finalize, leading to annoying data losses.
>
> 2. remember.el only allows a single text input at a time. org-capture
>makes it possible for users to write multiple notes in parallel.
>
> I am wondering if it would be possible to have the above two key
> features supported by remember.el. Then, org-capture.el could go back to
> re-using remember.el infrastructure and thus reduce code duplication.

This is, of course, desirable.  The real question is how much work it
will take and who will volunteer to do it.

On the face of things, remember.el does not comprise a huge amount of
code, and I don't see why the above two features couldn't be retrofitted
into it.

Patches welcome.

Re: org-assert-version considered harmful

[Stefan Monnier]

>>> But then it will not run during byte-compilation.
>> Yeah, I was assuming that you had replaced all `require`s with
>> `org-require-with-shadowcheck`, but that's probably not what you'd done.
> That's exactly what I have done.

Ah.  The issue comes from the fact that `require` is treated specially
by the byte compiler, so if you define `org-require-with-shadowcheck` as
a function it indeed won't do quite the same as `require`.

The way `require` is treated specially by the byte-compiler only affects
top-level uses (making them behave as if they're wrapped inside
`eval-and-compile`).  So you want to use `eval-and-compile` only for
those `require`s that are at top-level.

Personally, I'd only change those `require`s that load `org-macs`, which
should be enough to cover almost all cases (and I wouldn't just
silently reload the file, but I'd also emit a warning explaining that
we detected a bad situation and using a workaround since that
workaround is not 100% reliable anyway).


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

>> For this one I can see the problem.  You define:
>>
>> (defmacro org-require-with-shadowcheck (feature)
>>   [...]
>>   `(eval-and-compile ...))
>>
>> so it will behave like a function, except that it's also
>> executed during macroexpansion, so the (require 'org-element) within
>> `org-set-modules` will be eagerly executed while loading `org.el` :-(
>>
>> You should define `org-require-with-shadowcheck` as a function (just
>> like `require`).
>
> But then it will not run during byte-compilation.

Yeah, I was assuming that you had replaced all `require`s with
`org-require-with-shadowcheck`, but that's probably not what you'd done.

Not knowing what you had done (beside define
`org-require-with-shadowcheck`), it's hard to reproduce/investigate, tho.


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

> My attempt to use shadowcheck idea you proposed failed with some very
> strange errors and I gave up.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311

For this one I can see the problem.  You define:

(defmacro org-require-with-shadowcheck (feature)
  [...]
  `(eval-and-compile ...))

so it will behave like a function, except that it's also
executed during macroexpansion, so the (require 'org-element) within
`org-set-modules` will be eagerly executed while loading `org.el` :-(

You should define `org-require-with-shadowcheck` as a function (just
like `require`).

> Although, part of the problem was
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65286 which does not seem
> to be reproducible by others.

Haven't tried to look into this one yet.


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

Ihor Radchenko [2023-08-16 11:08:15] wrote:
> Ihor Radchenko  writes:
>> Stefan Monnier  writes:
>>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>>> from the new version the already loaded files from the old version.
>>> It suffers from a different set of problem :-(
>>> [ I suspect `defvar` is the main problem for that solution.  ]
>>
>> Could it be possible to force require use certain package version and
>> automatically re-load a package when older version is being loaded?
>
> After trying several more approaches,

[ Side note: did you keep notes about the various approaches you tried
  and their respective downsides?  E.g. I'm curious what were the
  problems linked to my proposal of using a `require-with-check` like
  the one below my sig.  ]

> I now came up with yet another idea.  Instead of fiddling with load
> internals, compilation, or load-path, what about making sure that Org
> libraries include version info directly?

That should work.  It implies a fair bit more churn in the code, tho,
but I guess you plan to automate it via some scripts?


Stefan


(defun require-with-check (feature  filename noerror)
  "If FEATURE is not already loaded, load it from FILENAME.
This is like `require' except if FEATURE is already a member of the list
‘features’, then we check if this was provided by a different file than the
one that we would load now (presumably because `load-path' has been
changed since the file was loaded)."
  (let ((lh load-history)
(res (require feature filename noerror)))
;; If the `feature' was not yet provided, `require' just loaded the right
;; file, so we're done.
(if (not (eq lh load-history)) res
  ;; If `require' did nothing, we need to make sure that was warranted.
  (let ((fn (locate-file (or filename (symbol-name feature))
 load-path (get-load-suffixes
;; If the right file was indeed loaded already, we're done.
(if (assoc fn load-history) res
  (funcall (if noerror #'warn #'error)
   "Feature provided by other file: %S" feature)
  res)

Re: New Orgmode LaTex Document Class ?

[Stefan Nobis]

Ihor Radchenko  writes:

> I'd prefer to put some more generic reference. Some info manual or
> good stable URL link that has explanations about kpsewhich and other
> LaTeX basics.

What about

   http://mirrors.ctan.org/info/latex-doc-ptr/latex-doc-ptr.pdf

No direct references to kpsewhich, but I agree, that this is already a
rather specialized tool. But there are pointers to all the entry level
tutorials and resources and also some of the rather often asked for
packages.

-- 
Until the next mail...,
Stefan.

Re: New Orgmode LaTex Document Class ?

[Stefan Nobis]

David Masterson  writes:

> I want to install a resume document class for LaTex

There are the variables org-latex-classes and org-latex-default-class
on the Org side, but that's only about some structural metadata (how
to map Org headline levels to LaTeX structure macros).

To find the new class file you have to put it into a folder where
LaTeX will find it. Org just puts the name of the class into the TeX
file and everything else is up to LaTeX.

Usually, on Unix systems, there is the optional hierarchy $HOME/texmf
where you can store you private, local files. It is a good idea to
mimic the usual TeX directory structure, therefore class and style
files for LaTeX should go into $HOME/texmf/tex/latex (you may add
subdirectories there).

Nowadays it should suffice to just drop your class file there and
everything should work on the LaTeX side.

A quick check whether LaTeX will be able to find the file could be
done with the tool kpsewhich:

kpsewhich myltxclass.cls

This tool uses the same configuration and search algorithms for the
files as the TeX engines. So if kpsewhich finds the file, the engines
should find it too.

One side note: On macOS the default path for the user texmf tree is
$HOME/Library/texmf. On all systems you may find the correct base
directory for the user texmf tree with the command

kpsewhich -var-value TEXMFHOME

Hope this helps.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> Though ideally all the necessary fonts should be provided by
> TeXLive. I am not sure why they are not yet there in 2023.

First problem: Is there any free/libre font out there that has a
really broad and comprehensive coverage of Unicode glyphs? I really
don't know, but from time to time I hear about fonts that I assumed to
have good Unicode coverage that this is not the case (e.g. TeX Gyre).
I think, it is just an enormous amount of work to produce a complete
Unicode font (even more so, if it should look nice).

The other problem: Not everyone does a full installation of TeX Live.
So even if good fonts are available, they are not always installed on
every system (but this part could be mitigated by documentation and/or
error messages and hints).

But I'm no Unicode or font expert (I only need latin letters). I'm
just impressed what is already possible and about all the work done by
volunteers. And sometimes I'm astonished by how much work is still to
do for a complete and smooth Unicode experience. :)

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> AFAIR, the basic problem is that we cannot guarantee that any given
> UTF font is installed.

Yes, indeed. Probably the best route is to make tweaking as easy as
possible. There are still too few (if any) really comprehensive (and
good looking) Unicode fonts available.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

"Dr. Arne Babenhauserheide"  writes:

> Isn’t the speed more relevant for large documents?

I always had the impression that luatex has mostly a rather fixed
overhead. Maybe that's because many of my larger documents make quite
some use of TikZ and most time may be spend there. Therefore I assumed
the fixed overhead does not matter that much for larger documents. But
I did no real benchmarks or performance comparisons and it might
depend of the kind of document and packages used.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

BTW: One of the discussion points in that thread has been the problem
of default fonts. With pdflatex the default font is CM (Computer
Modern) and if the appropriate packages are installed, you
automatically get cyrillic letters. That's why Max is a fan of this
solution.

With lualatex the default font is LM (Latin Modern; quite similar to
CM, but some metrics differ). And AFAIK LM is still worse in the range
of supported Unicode characters.

But only recently I discovered a package called "fontsetup". And this
package seems to provide a big step towards the goal discussed in the
above mentioned thread: Provide default fonts for most common
situations. The goal of fontsetup is more about easy switching between
different fonts, e.g. with the option "cambria" set everything up such
that the Microsoft Cambria font family is used and fall back to proper
fonts where Cambria has gaps. But that's also something that would be
nice for Org. Maybe we should have a closer look at this (I have no
real world experience with this package, only played a little bit with
it).

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

Yes, for sure. But I have the impression that newer versions of luatex
have become a bit faster (maybe it's just a subjective impression that
I want to be true, because I don't want to regret the complete switch
to luatex). :)

On the other hand: Luatex is much more flexible and has better support
for modern fonts and modern font render engines.

It depends what one assumes to be the most common use case for Org. If
it's many rather short and simple documents then pdftex should suffice
most of the time and the fast compile speed will matter. If we want to
support as many different situations out of the box, I think luatex
would be the better/easier way - at the cost of slower compilation
speeds.

Another approach: Use pdftex for simple/short documents and make
selection of luatex as backend engine per document as easy as
possible. Additionally, we might try to detect situations in which
luatex would be the better choice (e.g. certain languages). But this
would certainly be more work and lead to more complex code.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

andrés ramírez  writes:

> I have tried the snippet. But It shows just Japanese and the other
> paragraphs are not present on the PDF.

That's quite strange. I just re-tested with emacs -Q (Emacs 28.2 with
integrated Org 9.5.5). It generates the following tex file:

--8<---cut here---start->8---

% Created 2023-07-02 Sun 16:49
% Intended LaTeX compiler: lualatex
\documentclass[11pt]{article}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{luatexja}
\date{}
\title{Doc multi-lingual}
\hypersetup{
 pdftitle={Doc multi-lingual},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.2 (Org mode 9.5.5)}, 
 pdflang={Jp}}
\begin{document}

\maketitle

\section*{Español}
\label{sec:orgfec75bb}
Hola
\section*{English}
\label{sec:org36763e7}
Hi
\section*{French}
\label{sec:org8e5a1dd}
Ceci c'est en Français
\section*{Japanese}
\label{sec:org70cd53d}
ダウンロード
\end{document}

--8<---cut here---end--->8---

When I compile this file with lualatex, everything looks as expected
to me. BTW: I'm using TeX Live 2023 with all recent updates.

Also, from the LaTeX perspective I see nothing that should prevent the
latin letters from being shown in the final PDF. Here are the fonts
used:

--8<---cut here---start->8---

% pdffonts foo.pdf
name type  encoding emb sub 
uni object ID
 -  --- --- 
--- -
BRVOXH+LMRoman17-Regular CID Type 0C   Identity-H   yes yes 
yes  8  0
XVVEIR+LMRoman12-BoldCID Type 0C   Identity-H   yes yes 
yes 10  0
HIWCUH+LMRoman10-Regular CID Type 0C   Identity-H   yes yes 
yes 11  0
EPCPZB+HaranoAjiMincho-Regular   CID Type 0C   Identity-H   yes yes 
yes 15  0

--8<---cut here---end--->8---

Maybe there are some other configurations on the Emacs or LaTeX side
on your system that changes some of the defaults?

--
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Hi.

I got curious and it seems if you are willing to use lualatex (which
is, I think, currently the most actively developed engine and nowadays
a really good choice), the following solution should work:

--8<---cut here---start->8---

#+TITLE: Doc multi-lingual
#+options: author:nil email:nil toc:nil num:nil date:nil
#+LATEX_COMPILER: lualatex
#+LANGUAGE: jp
#+LaTeX_Header: \usepackage{luatexja}

* Español
Hola
* English
Hi
* French
Ceci c'est en Français
* Japanese
ダウンロード

--8<---cut here---end--->8---

The crucial parts are using lualatex and loading the package
"luatexja". It seems, that the package luatexja is currently one of
the best options to produce Japanese output and it is actively
developed. There is also quite a bit of documentation (see e.g. with
"texdoc luatexja" on the CLI or https://www.ctan.org/pkg/luatexja).

I have no experience with Japanese output and I'm unable to read
Japanese, so I could not judge the correctness or quality. But the
above approach seems to work quite well and it might be possible to
support this solution from the Org side (because only a single package
has to be loaded). The requirements seem to be OK (roughly TeXlive
2020 or newer). The package automatically sets up required fonts (but
it is still possible to override the default font settings) and even
with the default configuration it is possible to use Japanese fonts
inside math mode.

-- 
Until the next mail...,
Stefan.

Re: [RFC] Refactoring org-element API

[Stefan Nobis]

Hi Ihor,

thank you for all your great work. I did not dive deep into all the
details, but the overview you provided sounds sensible.

One minor nitpick: I would prefer a function like
~org-element-property-1~ to be named e.g. ~org-element-property-lazy~
(or something similar), because the "-1" is just obfuscation to me.

--
Until the next mail...,
Stefan.

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

> I have noticed that neither `package--reload-previously-loaded` nor code
> loading already compiled package unload the loaddefs file. E.g. I added

The state of our unloading support is not good enough to use it blindly,
indeed: it's too easy/common to have packages where `unload` leaves you
with an Emacs that has serious problems (including being unusable).

So, instead we limit ourselves to force-reloading files which tends to
be much more harmless (tho in theory of course it's just as bad).
It also tends to be sufficient.


    Stefan

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Jean Louis  writes:

> Specifying time zone is not ambiguous as long as you use the TZ
> database for specifications!

That's wrong and you know it. For example

   [2023-10-29 02:30 @Europe/Berlin]

is ambiguous. Period.

And that some examples got a bit off has been quite obvious and has
already been stated. So its not necessary to flog dead horses.

It would also be nice to eventually recognize, that we are talking
about readable syntax for humans, that is sometimes generated,
sometimes manually typed. Most of you comments does not really
resonate with this crucial design goal.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> Note that an alternative is 

>  [2022-11-12 10:30-11:00]
>  [2022-11-12 10:30-11]
>  [2022-11-12 10:30-11:00-11]

> which is much less confusing.

Hmmm... is it? I read a lot different timestamps these days and
currently I'm very careful reading them, especially while considering
syntax details. Therefore I'm reading slowly and only few timestamps
at once.

But real life sometimes get hectic and stressful. And then I might
only throw a glance at timestamps, hoping to get the important details
- surely I will remember all the important details. :) In these cases I
would much prefer a syntax that is a bit less terse like

>  [2022-11-12 10:30 @+02]

So I would vote for Timothys variant.

Considering Timothys other proposal:

>> I like the way that combining these features works, but I do wonder if 
>> perhaps
>> warning when these two bits of information don’t match should be the default
>> behaviour, and the `!' used to specify which of them should be prioritised?

I do not like the semantics.

>> ┌
>> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
>> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

I read "@+07,!Asia/Singapore" as "use UTC offset +07 but be aware of
time zone Asia/Singapore, from which I got the offset in the first
place".

On the other hand, I read "@+07,Asia/Singapore" as "use UTC offset
+07, which I got from the Asia/Singapore time zone".

So for me a possible warning should go with the "!" variant. In the
case without "!", for me the syntax suggests a more informative
meaning for the time zone name part.

Therefore I would vote for Ihors variant for this part. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> ...which stems from the fact that the very concept of "time zone" is
> somewhat ambiguous, too.

Yes - I think most of us here see that. Therefore I really appreciate
the flexible timestamp format Ihor suggested.

> If you really want to have fun with this (and this thread hasn't
> satisfied your thirst ;-) see [1].

Thanks for the link. Very interesting details that I didn't know
about yet.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> [2023-03-29 02:30 @Europe/Berlin] is special.

I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> it /is/ ambiguous.

As far as I understand the definitions, the point in time "2023-03-23
02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.

A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
Strictly speaking, this point in time does not exist, because in the
night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
directly to 03:00 in the time zone Europe/Berlin. Therefore the
/interpretation/ of this timestamp is ambiguous.

The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
02B:30 (02:30 UTC+0100) in this night of switching back from DST to
normal time!

So, in general, only using the time zone name may indeed lead to
ambiguous interpretations of timestamps.

-- 
Until the next mail...,
Stefan.

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

> - "emacs -l org" to simulate a regular user session with some opened files.
> - Update to Org-9.6 from ELPA.
> - Close emacs and start it again "emacs -l org"
>
> Result:
> byte-code: Invalid function: org-assert-version

Hmm... there's code in `package.el` intended to avoid that problem, but
clearly it's failing here.  Could Someone™ investigate why that code
doesn't do its job.

The code in question is in `package--reload-previously-loaded` and
my understanding is that it should cause `org-macs` to be reloaded from
the Org-9.6 version of the code before the new code gets compiled, and
that new version does define the `org-assert-version` version, so those
macro calls should then be compiled correctly.

[ The approach used in `package--reload-previously-loaded` has its
  weaknesses, but AFAIK it *should* be able to avoid the above error.  ]


Stefan

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hi,

On Thu, Dec 15, 2022, at 13:16, Ihor Radchenko wrote:
> 1. Check the value of `org-element--cache-change-tic' right after
>opening an Org file 

first its 1, 

(when I start fresh and add 1 byte to the buffer the value is 13955)

> and the values of `after-change-functions' and
>`after-change-functions' in Org buffer after you see the warning.

after starting the =t= agenda (which results in the warnings):

the value of org-element--cache-change-tic is still 1,

the value of after-change-functions is
`(org-element--cache-after-change jit-lock-after-change 
flyspell-after-change-function org-fold-core--fix-folded-region t 
ws-butler-after-change)`

(I disabled `ws-butler` because that sounded suspicious, but that did not 
resolve the warnings)


> 2. If you can, try to load Emacs with minimal Org-related settings.
>Then, try to load agenda and let me know if you see the warning.

I did some manual bisecting of my config, and I noticed that the warnings in 
"Media.org" go away when I remove `(org-startup-align-all-tables t)` from my 
config.  

So I did some more digging, reduced 
my config to just contain `org-startup-align-all-tables` set to t, 
my agendas limited to Media.org, 
and removed most headings from Media.org.

With a minimal Media.org I get a "Org parser error",
see here for sample and backtrace:
https://gist.github.com/stefan2904/5a2b33d42a947f36402b548d9b186b67

(here the parser error turns into an incorrect error when I change the length 
of the URL ...)


With a very minimal Media.org I get a "Cached element is incorrect",
apparently because the table is not aligned?
see here for sample file and backtrace:
https://gist.github.com/stefan2904/688afdc2ebfeece8e0fa19a24d9ca321

Both errors go away when I set `(org-startup-align-all-tables nil)`.

>It looks to me like you have something unusual in your Org setup or
>    some third-party package interfering.


Best,
 Stefan

Re: [BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hello,

sorry, I was not aware of that. I am sending the full backtrace unredacted to 
you directly. 

The respective org files are in a git repo, and there I don't see any edits in 
the files since starting emacs (also not after manually saving all org buffers).

Let me know if you need anything else.

Best,
 Stefan


On Thu, Dec 15, 2022, at 09:14, Ihor Radchenko wrote:
> Thanks, but a small portion of the backtrace is not helpful here.
> "Cached element is incorrect" appears to be related to some buffer edits
> being missed by the cache, which can only be visible by looking at the
> full history of registered cache edits.
>
> There is a reason why this much backtrace is generated. The real problem
> often appears long time before the actual issue is caught by
> self-verification code.

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

Max Nikulin [2022-12-14 23:02:53] wrote:
> On 14/12/2022 21:35, Stefan Monnier wrote:
>>>  Like I said in another message that I sent just before receiving yours
>>>  my conclusion came from the fact that hitting 'C-h v' with the cursor
>>>  on 'org-goto-interface' provided nothing.  It was the first time this
>>>  ever happened to me.  I did try to explicitly enter the variable's
>>>  name by entering 'org-goto', which (like 'org-go') is not
>>>  enough: it is completed to 'org--goto'.
>> AFAICT this is a missing feature: we obey `help-enable-autoload` in
>> `describe-function` but we fail to do the same autoloading dance in
>> `describe-variable`.
>
> I think, the difference is interactive vs. non-interactive calls rather than
> `describe-function' vs. `describe-variable'. What misses this feature is
> `customize-variable'.
>
> Completion failure for "org-to" happened because result of
> `register-definition-prefixes' calls is not considered as options. I am
> aware that it may give false positives, but I still believe they should
> be added.

I'm sorry, but I don't understand what you're saying.

> Though I believe that org mixed version issue happens due to transitional
> dependency of some third party package on org or something like (require
> 'org-protocol) that can not be loaded on demand.

Hmm... indeed the "Subject:" talks about mixed versions, yet I was
discussing something not directly related.  Looks like I got off-topic
somewhere along the way without noticing, sorry.


Stefan

[BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

While trying to reproduce the "Org parser error" error issue (see other 
thread), I got multiple "Cached element is incorrect" warnings (backtrace 
excerpt below).

Here is one that appeared when trying to loading the =t= agenda:

-- quote --

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"Podcasts\" :begin 684093 :end 741628 
:pre-blank 0 :contents-begin 684104 :contents-end 741627 :robust-begin 684148 
:robust-end 741625 :level 1 :priority nil :tags nil :todo-keyword nil 
:todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp 
nil :post-affiliated 684093 :ID \"podcasts\" :title \"Podcasts\" :mode nil 
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1 
:contents-end 746346 :end 746346 :robust-begin 3 :robust-end 746344 :post-blank 
0 :post-affiliated 1 :path \"/home/stefan/PRIVATE/journal/org/Media.org\" :mode 
org-data :CATEGORY \"Media\" :cached t"
 The real element is: "(headline (:raw-value \"Podcasts\" :begin 684093 :end 
740615 :pre-blank 0 :contents-begin 684104 :contents-end 740614 :robust-begin 
684148 :robust-end 740612 :level 1 :priority nil :tags nil :todo-keyword nil 
:todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp 
nil :post-affiliated 684093 :ID \"podcasts\" :title \"Podcasts\" :mode nil 
:granularity element :parent nil))"
 Cache around :begin:
nil
nil
nil Disable showing Disable logging

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"My Podcast Recommendations\" :begin 
684150 :end 692232 :pre-blank 1 :contents-begin 684181 :contents-end 692231 
:robust-begin 684183 :robust-end 692229 :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684150 :title \"My Podcast 
Recommendations\" :mode nil :granularity element :cached t :parent (headline 
(:raw-value \"Podcasts\" :begin 684093 :end 741628 :pre-blank 0 :contents-begin 
684104 :contents-end 741627 :robust-begin 684148 :robust-end 741625 :level 1 
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 684093 
:ID \"podcasts\" :title \"Podcasts\" :mode nil :granularity element :cached t 
:parent (org-data ...)"
 The real element is: "(headline (:raw-value \"My Podcast Recommendations\" 
:begin 684150 :end 691219 :pre-blank 1 :contents-begin 684181 :contents-end 
691218 :robust-begin 684183 :robust-end 691216 :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684150 :title \"My Podcast 
Recommendations\" :mode nil :granularity element :parent (headline (:raw-value 
\"Podcasts\" :begin 684093 :end 740615 :pre-blank 0 :contents-begin 684104 
:contents-end 740614 :robust-begin 684148 :robust-end 740612 :level 1 :priority 
nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 684093 
:ID \"podcasts\" :title \"Podcasts\""
 Cache around :begin:
nil
nil
nil Disable showing Disable logging

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"Stefan's Podcast List 1\" :begin 
684191 :end 692232 :pre-blank 1 :contents-begin 684220 :contents-end 692231 
:robust-begin 684222 :robust-end 692229 :level 3 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684191 :title \"Stefan's 
Podcast List 1\" :mode nil :granularity element :cached t :parent (headline 
(:raw-value \"My Podcast Recommendations\" :begin 684150 :end 692232 :pre-blank 
1 :contents-begin 684181 :contents-end 692231 :robust-begin 684183 :robust-end 
692229 :level 2 :priority nil :tags nil :todo-keyword nil :todo-type nil 
:post-blank 1 :footnote-section-p nil :archivedp nil 

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

(plain-list (:type unordered :begin 712169 :end 712176 :contents-begin 712169 
:contents-end 712175 :structure ((712169 0 "- " nil "[ ]" nil 712175)) ...))

For the record, the last heading in Stefan.org looks like this:

-- quote --

** DONE [#A] Set alarm clock for presentation
CLOSED: [2022-12-11 Sun 13:38] SCHEDULED: <2022-12-09 Fri 19:00>
:PROPERTIES:
:CREATED:  [2022-12-07 Wed 18:01]
:ID:   efe672fa-9607-4cd2-858e-0ca89838bd56
:END:
:LOGBOOK:
- Refiled on [2022-12-07 Wed 18:01]
:END:

- [ ]


-- endquote--

That's a heading created based on a capture template, where I did not set that 
checklist item.

Best,
 Stefan

On Wed, Dec 14, 2022, at 19:32, Ihor Radchenko wrote:
> Thanks!
>
> What happens if you run M-: (org-element-at-point (point-max))
> from Stefan.org?

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hi Ihor, all,

thanks for the fast reaction.

Here is the backtrace, again from the =a= agenda:

https://gist.githubusercontent.com/stefan2904/0bb5d9db84664a4f4225cd809c294964/raw/e0ac2ec53d4b1d2fed57e440b8fb23157ecbab3d/redacted-backtrace.log

Best,
 Stefan

On Wed, Dec 14, 2022, at 16:17, Ihor Radchenko wrote:
> Thanks for reporting!
>
> Could you please set org-element--cache-self-verify to 'backtrace and
> org-element--cache-self-verify-frequency to 1.0? Then, try to reproduce
> the error and post the full (huge) backtrace.
>
> Note that the backtrace will contain parts of your file, so you may
> consider stripping the sensitive parts of sharing it privately.

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

> similar issues with several important Org components (ol-* and ob-*). In
> particular, ob-*.el packages affect Org simply by defining function
> symbols with specific name patters (by ob-core.el design).
> Achieving no side effects is difficult in practice.

That's true.  It can be a balancing act.

> Also, note that side effects are not uncommon in Elisp packages.
> Including, built-ins, like rect.el.
> dired+ comes to mind among popular third-party packages.

Most of them are plain bugs, tho (typically fixed by introducing an
autoloaded minor-mode, so the package is activated by enabling the
minor mode rather than by `require`ing the package).

> Like I said in another message that I sent just before receiving yours
> my conclusion came from the fact that hitting 'C-h v' with the cursor
> on 'org-goto-interface' provided nothing.  It was the first time this
> ever happened to me.  I did try to explicitly enter the variable's
> name by entering 'org-goto', which (like 'org-go') is not
> enough: it is completed to 'org--goto'.

AFAICT this is a missing feature: we obey `help-enable-autoload` in
`describe-function` but we fail to do the same autoloading dance in
`describe-variable`.


Stefan

[BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hello everyone,

I recently upgraded to Org 9.6 via Git (and to Emacs 28 with nativecomp), and 
since then I get this kind of warnings all the time. They appear at different 
spots in my org files and there is nothing special with the headings in 
question.

This specific warning appears when I load the standard =a= agenda:

---quote---

Warning (org-element-cache): org-element--cache: Org parser error in 
Stefan.org::#. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re \"]+)>\" :fail-re 
\"]+)>\" :narrow t)
  org-agenda-get-deadlines()
  org-agenda-get-day-entries(\"/home/stefan/PRIVATE/journal/org/Stefan.org\" 
(12 12 2022) :deadline :scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries 
\"/home/stefan/PRIVATE/journal/org/Stefan.org\" (12 12 2022) (:deadline 
:scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)
"

---endquote---

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2022-05-31
Package: Org mode version 9.6 (release_9.6-90-gf49ee9 @ 
/home/stefan/.emacs.d/contrib/org-mode/lisp/)


Best,
 Stefan

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

>> On a related note, is it normal that package like org-mouse.el gets
>> loaded upon calling C-h f org-mouse-  completion prompt?

Yes.  See `help-enable-completion-autoload`.

>> I am asking because org-mouse.el advises some functions and its loading
>> may cause unexpected consequences. See
>> https://orgmode.org/list/87r0x6sju1@fastmail.fm
> I think org-mouse.el should be fixed not to cause such effects just by
> loading it.  It should do that only when it is actually used.

Exactly.  Merely loading a file should not affect Emacs's behavior in
any significant way.


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

> when using unload-feature), so yes, ideally Emacs would make it
> possible to have multiple versions of the same package.

Having multiple versions *installed* has been supported since "for ever"
(AFAIK support for that was added very early in `package.el`s life,
before Emacs-24.1).

Having multiple versions loaded at the same time in an Emacs session?
I think we're very far from supporting that.

BTW, rather than unloading, `package.el` relies on forcibly "re"loading
from the new version the already loaded files from the old version.
It suffers from a different set of problem :-(
[ I suspect `defvar` is the main problem for that solution.  ]


Stefan

[PATCH] Improve Swedish entry in org-export-dictionary

[Stefan Kangas]

The attached patch improves the Swedish localization of
org-export-dictionary, and adds several missing entries.
From 12277e509118591d7ad7617494f6db45920b4f4b Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sat, 3 Dec 2022 12:31:13 +0100
Subject: [PATCH] Improve Swedish entry in org-export-dictionary

* lisp/ox.el (org-export-dictionary): Improve Swedish localization.
---
 lisp/ox.el | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 5c0a8f242..22447b929 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6000,7 +6000,7 @@ them."
  ("ro" :default "Autor")
  ("ru" :html "" :utf-8 "Автор")
  ("sl" :default "Avtor")
- ("sv" :html "Frfattare")
+ ("sv" :default "Författare")
  ("tr" :default "Yazar")
  ("uk" :html "" :utf-8 "Автор")
  ("zh-CN" :html "" :utf-8 "作者")
@@ -6022,6 +6022,7 @@ them."
  ("ru" :html "()"
   :utf-8 "(Продолжение)")
  ("sl" :default "Nadaljevanje s prejšnje strani")
+ ("sv" :default "Fortsättning från föregående sida")
  ("tr" :default "Önceki sayfadan devam ediyor"))
 ("Continued on next page"
  ("ar" :default "التتمة في الصفحة التالية")
@@ -6040,6 +6041,7 @@ them."
  ("ru" :html "( )"
   :utf-8 "(Продолжение следует)")
  ("sl" :default "Nadaljevanje na naslednji strani")
+ ("sv" :default "Fortsätter på nästa sida")
  ("tr" :default "Devamı sonraki sayfada"))
 ("Created"
  ("cs" :default "Vytvořeno")
@@ -6048,6 +6050,7 @@ them."
  ("pt_BR" :default "Criado em")
  ("ro" :default "Creat")
  ("sl" :default "Ustvarjeno")
+ ("sv" :default "Skapat")
  ("tr" :default "Oluşturuldu"))
 ("Date"
  ("ar" :default "بتاريخ")
@@ -6193,6 +6196,7 @@ them."
  ("ru" :html " "
   :utf-8 "Список распечаток")
  ("sl" :default "Seznam programskih izpisov")
+ ("sv" :default "Programlistningar")
  ("tr" :default "Program Listesi")
  ("zh-CN" :html "" :utf-8 "代码目录"))
 ("List of Tables"
@@ -6238,6 +6242,7 @@ them."
  ("ru" :html ""
   :utf-8 "Распечатка")
  ("sl" :default "Izpis programa")
+ ("sv" :default "Programlistning")
  ("tr" :default "Program")
  ("zh-CN" :html "" :utf-8 "代码"))
 ("Listing %d:"
@@ -6259,6 +6264,7 @@ them."
  ("ru" :html " %d.:"
   :utf-8 "Распечатка %d.:")
  ("sl" :default "Izpis programa %d")
+ ("sv" :default "Programlistning %d:")
  ("tr" :default "Program %d:")
  ("zh-CN" :html "%d" :utf-8 "代码%d "))
 ("References"
@@ -6273,6 +6279,7 @@ them."
  ("pt_BR" :html "Referncias" :default "Referências" :ascii "Referencias")
  ("ro" :default "Bibliografie")
  ("sl" :default "Reference")
+ ("sv" :default "Referenser")
  ("tr" :default "Referanslar"))
 ("See figure %s"
  ("cs" :default "Viz obrázek %s")
@@ -6285,6 +6292,7 @@ them."
  ("pt_BR" :default "Veja a figura %s")
  ("ro" :default "Vezi figura %s")
  ("sl" :default "Glej sliko %s")
+ ("sv" :default "Se illustration %s")
  ("tr" :default "bkz. şekil %s"))
 ("See listing %s"
  ("cs" :default "Viz program %s")
@@ -6296,6 +6304,7 @@ them."
  ("pt_BR" :default "Veja a listagem %s")
  ("ro" :default "Vezi tabelul %s")
  ("sl" :default "Glej izpis programa %s")
+ ("sv" :default "Se programlistning %s")
  ("tr" :default "bkz. program %s"))
 ("See section %s"
  ("ar" :default "انظر قسم %s")
@@ -6316,6 +6325,7 @@ them."
  ("ru" :html ".  %s"
   :utf-8 "См. раздел %s")
  (&

[PATCH] Fix two typos

[Stefan Kangas]

The attached patch fixes two typos.
From bb00d528679174337dd9c7b26ee1514a21ce Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sat, 3 Dec 2022 11:43:51 +0100
Subject: [PATCH] ; Fix two typos

---
 testing/lisp/test-org-datetree.el | 2 +-
 testing/lisp/test-org.el  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/testing/lisp/test-org-datetree.el b/testing/lisp/test-org-datetree.el
index 1f0169397..59ef8c33b 100644
--- a/testing/lisp/test-org-datetree.el
+++ b/testing/lisp/test-org-datetree.el
@@ -129,7 +129,7 @@
 (org-trim (buffer-string)))
 
 (ert-deftest test-org-datetree/find-iso-week-create ()
-  "Test `org-datetree-find-iso-date-create' specificaiton."
+  "Test `org-datetree-find-iso-date-create' specification."
   (let ((org-blank-before-new-entry '((heading . t
 ;; When date is missing, create it.
 (should
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 32026b74e..a2ceb3916 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5918,7 +5918,7 @@ Paragraph"
 :B: 1
 :END:"
 	(org-buffer-property-keys
-  ;; Retrieve muliple properties in the same drawer.
+  ;; Retrieve multiple properties in the same drawer.
   (should
(equal '("A" "B")
 	  (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:B: 2\n:END:"
-- 
2.35.1

[PATCH] Remove 'org-speed-commands-user' warning

[Stefan Kangas]

Just a small cleanup in preparation of 9.6, see attached.
From bb02572eb41f61023dc421f80709fa602a9a7822 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Mon, 21 Nov 2022 12:01:29 +0100
Subject: [PATCH] Remove 'org-speed-commands-user' warning

* lisp/org-keys.el (org-speed-command-help): Remove
'org-speed-commands-user' warning.
---
 lisp/org-keys.el | 4 
 1 file changed, 4 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 79e34cbd1..95f64a3f9 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -808,10 +808,6 @@ command."
   (interactive)
   (unless org-use-speed-commands
 (user-error "Speed commands are not activated, customize `org-use-speed-commands'"))
-  ;; FIXME: remove this warning for 9.6
-  (when (boundp 'org-speed-commands-user)
-(message "`org-speed-command-user' is obsolete, please use `org-speed-commands'")
-(sit-for 3))
   (with-output-to-temp-buffer "*Help*"
 (princ "Speed commands\n==\n")
 (mapc #'org-print-speed-command
-- 
2.35.1

bug#35453: 26.1; Poor performance of vertical-motion in large org buffer

[Stefan Kangas]

For posterity, this was closed by feature/noverlay being merged:
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg02166.html

Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Stefan Kangas]

Ihor Radchenko  writes:

>> Note that with the suggested feature, any link you follow risks being
>> loaded in Org mode, before the user even has a chance to inspect the
>> file.  Which Org features, currently existing or introduced in the
>> future, would EWW have to add workarounds for?
>
> That's not the case. Org never loads arbitrary code on loading the file
> without querying the user.

We seem to be miscommunicating.  In the above, I was merely referring to
whether org-mode is run when visiting some URL or not, which AFAIU is a
binary thing (it either does, or it doesn't).

You seem to be talking about security features in org-mode itself, which
is related, but not the same thing.  I agree that there are various
security features in org-mode.  I still don't think that we should run
org-mode just because some URL requests it.

To reiterate what I said, security problems are hard to audit and
discover.  We shouldn't expose users to additional risks just to add
such a minor convenience feature.  It is not a good trade-off.

> Strictly speaking, even eww-mode may run arbitrary code given that user
> puts something into eww-mode-hook.

My concern is not that the users should run their own code, but that
they will inadvertently run (potentially malicious) code provided by
others.

> I'd say that it will be safer to take care about necessary precautions
> rather than leaving the user with the only option to run org-mode
> manually.

Adding a `safe-org-mode' would be an improvement, but orthogonal to
whether or not we should automatically load org-mode when visiting any
URL that presents itself as serving an org file.  I think we should not
do the latter.

> If necessary, we can introduce a special variable in Org mode that will
> disable all the potential third-party code evaluation, even if user has
> customized Org to execute code without prompt.

That would also be an improvement, yes.  It would be even better if such
a variable supported whitelisting, so that users could mark only
specific files as safe for these purposes.

Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Stefan Kangas]

Ihor Radchenko  writes:

> The "problem" with shell links you are describing is a question of
> setting variables and is also disabled by default.
>
> eww-mode, when loading Org page, could simply set
> org-link-shell-confirm-function to its default value.

Note that with the suggested feature, any link you follow risks being
loaded in Org mode, before the user even has a chance to inspect the
file.  Which Org features, currently existing or introduced in the
future, would EWW have to add workarounds for?

It is very hard to foresee which parts of Org will be problematic and
have to be disabled.  See the security vulnerability in enriched-mode
that prompted the release of Emacs 25.3, for example.

Adding this opens a can of worms that will expose unsuspecting users to
a whole class of new problems.  And the only benefit is to save some
users from having to type "M-x org-mode RET", or adding call to a
suitable hook.

All in all, this seems like a bad trade-off.  So I don't think we should
add such a feature.

Re: [PATCH] Three documentation patches

[Stefan Kangas]

Ihor Radchenko  writes:

> The patches look good, but I am unable to apply them onto current main:

Hmm, strange.  I've rebased on top of current main, and I'm resending
the resulting patches here.  I hope they work better.
From ffd00c1272dd876f64c9ef930d19988b6da5c2a3 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring

* lisp/org-agenda.el (org-stuck-projects): Add Info manual reference
to docstring.
---
 lisp/org-agenda.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e5df768ff..5b8133e81 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -614,13 +614,17 @@ you can then use it to define a custom command."
   '("+LEVEL=2/-DONE" ("TODO" "NEXT" "NEXTACTION") nil "")
   "How to identify stuck projects.
 This is a list of four items:
+
 1. A tags/todo/property matcher string that is used to identify a project.
-   See the manual for a description of tag and property searches.
-   The entire tree below a headline matched by this is considered one project.
+   See Info node `(org) Matching tags and properties' for a
+   description of tag and property searches.  The entire tree
+   below a headline matched by this is considered one project.
+
 2. A list of TODO keywords identifying non-stuck projects.
If the project subtree contains any headline with one of these todo
keywords, the project is considered to be not stuck.  If you specify
\"*\" as a keyword, any TODO keyword will mark the project unstuck.
+
 3. A list of tags identifying non-stuck projects.
If the project subtree contains any headline with one of these tags,
the project is considered to be not stuck.  If you specify \"*\" as
@@ -628,6 +632,7 @@ This is a list of four items:
the explicit presence of a tag somewhere in the subtree, inherited
tags do not count here.  If inherited tags make a project not stuck,
use \"-TAG\" in the tags part of the matcher under (1.) above.
+
 4. An arbitrary regular expression matching non-stuck projects.
 
 If the project turns out to be not stuck, search continues also in the
-- 
2.30.2

From d0c890d14382d3b4d1c0259f76f2478a0d1700ae Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:27 +0200
Subject: [PATCH 2/3] Improve documentation of org-agenda-skip-*

* doc/org-manual.org (Special Agenda Views): Improve indexing.
* lisp/org-agenda.el (org-agenda-skip-function)
(org-agenda-skip-entry-if, org-agenda-skip-subtree-if): Expand
docstrings.
(org-agenda-skip-if): Doc fix; clarify wording.
---
 doc/org-manual.org |  2 ++
 lisp/org-agenda.el | 33 +++--
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a20c8e50b..ddba84cab 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21345,6 +21345,8 @@ meaningful string suitable for the agenda view.
 
 #+vindex: org-odd-levels-only
 #+vindex: org-agenda-skip-function
+#+findex: org-agenda-skip-entry-if
+#+findex: org-agenda-skip-subtree-if
 Search for entries with a limit set on levels for the custom search.
 This is a general approach to creating custom searches in Org.  To
 include all levels, use =LEVEL>0=[fn:: Note that, for
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 5b8133e81..cadf5ffb8 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4204,12 +4204,19 @@ to t."
 If this function returns nil, the current match should not be skipped.
 Otherwise, the function must return a position from where the search
 should be continued.
-This may also be a Lisp form, it will be evaluated.
-Never set this variable using `setq' or so, because then it will apply
-to all future agenda commands.  If you do want a global skipping condition,
-use the option `org-agenda-skip-function-global' instead.
-The correct usage for `org-agenda-skip-function' is to bind it with
-`let' to scope it dynamically into the agenda-constructing command.
+
+This may also be a Lisp form that will be evaluated.  Useful
+forms include `org-agenda-skip-entry-if' and
+`org-agenda-skip-subtree-if'.  See the Info node `(org) Special
+Agenda Views' for more details and examples.
+
+Never set this variable using `setq' or similar, because then it
+will apply to all future agenda commands.  If you want a global
+skipping condition, use the option `org-agenda-skip-function-global'
+instead.
+
+The correct way to use `org-agenda-skip-function' is to bind it with `let'
+to scope it dynamically into the agenda-constructing command.
 A good way to set it is through options in `org-agenda-custom-commands'.")
 
 (defun org-agenda-skip ( element)
@@ -5122,12 +5129,18 @@ bind it in the options section.")
 
 (defun org-agenda-skip-entry-if ( conditi

[PATCH] Three documentation patches

[Stefan Kangas]

Please find attached three separate documentation patches.
From 269faa44ec18bb63c61ecba4cb232ceb0e46cd10 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring

* lisp/org-agenda.el (org-stuck-projects): Add Info manual reference
to docstring.
---
 lisp/org-agenda.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b608bdd29..612407c0a 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -614,13 +614,17 @@ you can then use it to define a custom command."
   '("+LEVEL=2/-DONE" ("TODO" "NEXT" "NEXTACTION") nil "")
   "How to identify stuck projects.
 This is a list of four items:
+
 1. A tags/todo/property matcher string that is used to identify a project.
-   See the manual for a description of tag and property searches.
-   The entire tree below a headline matched by this is considered one project.
+   See Info node `(org) Matching tags and properties' for a
+   description of tag and property searches.  The entire tree
+   below a headline matched by this is considered one project.
+
 2. A list of TODO keywords identifying non-stuck projects.
If the project subtree contains any headline with one of these todo
keywords, the project is considered to be not stuck.  If you specify
\"*\" as a keyword, any TODO keyword will mark the project unstuck.
+
 3. A list of tags identifying non-stuck projects.
If the project subtree contains any headline with one of these tags,
the project is considered to be not stuck.  If you specify \"*\" as
@@ -628,6 +632,7 @@ This is a list of four items:
the explicit presence of a tag somewhere in the subtree, inherited
tags do not count here.  If inherited tags make a project not stuck,
use \"-TAG\" in the tags part of the matcher under (1.) above.
+
 4. An arbitrary regular expression matching non-stuck projects.
 
 If the project turns out to be not stuck, search continues also in the
-- 
2.30.2

From f0af8f8e68e3953455c7ef5d08651da39ef86a01 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:27 +0200
Subject: [PATCH 2/3] Improve documentation of org-agenda-skip-*

* doc/org-manual.org (Special Agenda Views): Improve indexing.
* lisp/org-agenda.el (org-agenda-skip-function)
(org-agenda-skip-entry-if, org-agenda-skip-subtree-if): Expand
docstrings.
(org-agenda-skip-if): Doc fix; clarify wording.
---
 doc/org-manual.org |  2 ++
 lisp/org-agenda.el | 33 +++--
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d249f32d6..5de4f93c7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21159,6 +21159,8 @@ meaningful string suitable for the agenda view.
 
 #+vindex: org-odd-levels-only
 #+vindex: org-agenda-skip-function
+#+findex: org-agenda-skip-entry-if
+#+findex: org-agenda-skip-subtree-if
 Search for entries with a limit set on levels for the custom search.
 This is a general approach to creating custom searches in Org.  To
 include all levels, use =LEVEL>0=[fn:161].  Then to selectively pick
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 612407c0a..9189bbafb 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4203,12 +4203,19 @@ to t."
 If this function returns nil, the current match should not be skipped.
 Otherwise, the function must return a position from where the search
 should be continued.
-This may also be a Lisp form, it will be evaluated.
-Never set this variable using `setq' or so, because then it will apply
-to all future agenda commands.  If you do want a global skipping condition,
-use the option `org-agenda-skip-function-global' instead.
-The correct usage for `org-agenda-skip-function' is to bind it with
-`let' to scope it dynamically into the agenda-constructing command.
+
+This may also be a Lisp form that will be evaluated.  Useful
+forms include `org-agenda-skip-entry-if' and
+`org-agenda-skip-subtree-if'.  See the Info node `(org) Special
+Agenda Views' for more details and examples.
+
+Never set this variable using `setq' or similar, because then it
+will apply to all future agenda commands.  If you want a global
+skipping condition, use the option `org-agenda-skip-function-global'
+instead.
+
+The correct way to use `org-agenda-skip-function' is to bind it with `let'
+to scope it dynamically into the agenda-constructing command.
 A good way to set it is through options in `org-agenda-custom-commands'.")
 
 (defun org-agenda-skip ( element)
@@ -5121,12 +5128,18 @@ bind it in the options section.")
 
 (defun org-agenda-skip-entry-if ( conditions)
   "Skip entry if any of CONDITIONS is true.
-See `org-agenda-skip-if' for details."
+See `org-agenda-skip-if' for details about CONDITIONS.
+

Re: Use lexical-scoping in tests

[Stefan Monnier]

>> OK, here's a better version.  As you can see, it's not nearly as simple.
>
> Applied onto main + commits addressing all but one FIXME (the one about
> `find-file' in org-test.el).

Great, thanks,


Stefan

Re: Use lexical-scoping in tests

[Stefan Monnier]

>> +;; FIXME: `s' is a symbol, so (car-safe s) is always nil.
>> +;;(when (eq 'autoload (car-safe s))
>> +;;  (unintern s obarray))
>> +
>
> If I understand correctly, the intended version of this code is supposed
> to be
>
>   (when (autoloadp (symbol-function s))
> (unintern s obarray))
>
> the idea being "unloading" all the built-in org-related staff.
> However, make test will be failing then with byte-compiler error.
> I feel that the idea of the code is reasonable, but some detail of how
> autoloads work in Emacs is missed.

I don't see why you'd need to remove the existing autoloads: they don't
specify which directory the file will come from, so if the file still
exists in the new Org, the (old) autoload will load from the new Org,
as needed.

I mean it's OK to remove those autoloads, but really, those are usually
harmless and they are the least of your problems.  I think the things
we'd want/need to "remove" are those things which *aren't* autoloads.

Also `unintern` is a fairly powerful operation which can come with
undesirable side-effects, so I'd rather replace it with something less
risky like `fmakunbound`.

>> +   ;; FIXME: For the rare cases where we do need to mess with windows,
>> +   ;; we should let `body' take care of displaying this buffer!
>> (setq buffer (find-file file))
>
> Could you please elaborate about this fixme?

`find-file` displays the buffer in a window.  In most uses of this code
we don't care whether the buffer is displayed or not, so we should
probably use `find-file-noselect` instead.
[ As a rule of thumb, most uses of `find-file` (and `switch-to-buffer`)
  in ELisp code are the result of a misunderstanding from the coder who
  just uses the commands he's familiar with as a user.  But in Elisp,
  you generally want to use `find-file-noselect` (and `set-buffer`, or
  maybe `pop-to-buffer`) instead.  ]

I didn't make the change, tho, because some parts of the tests do care
about which buffer is displayed in which window, apparently, so it would
take more work.


Stefan

Re: Use lexical-scoping in tests

[Stefan Monnier]

> The fix is in preparation, but obviously I had tested my patch
> incorrectly (i.e. I probably compiled and tested another code than the
> one I had patched).

OK, here's a better version.  As you can see, it's not nearly as simple.


    Stefan
>From 9cd41bcbb6ca6771bd4c79f8b9d07241c67250ea Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Wed, 14 Sep 2022 17:21:37 -0400
Subject: [PATCH] testing: Make all files use `lexical-binding`

Mainly, add the corresponding cookie, but also add various `require`s
so that the compiler knows which vars should be trated as dynbound.
This does not fix all the warnings, but does try to eliminate
all those about "unused" variables.  For the variables truly unused,
the patch usually adds an underscore to their name to silence the warning.

Some of the fixes affect files which already used `lexical-binding`.
Not sure why the test worked before: maybe because the tests were run
without compiling them first (which could cause some of the
missing `require`d packages to be autoloaded before we got to the
problematic code, thus hiding the problem)?

I found some suspicious code, for which I added FIXMEs.

There are also a few changes to the main files.

* lisp/org-protocol.el (org-protocol-check-filename-for-protocol):
Don't call `server-edit` if it's not yet defined.  [ Needed to get
the tests to pass. ]

* lisp/ob-core.el (org-babel-temporary-directory)
(org-babel-temporary-stable-directory): Always define (and use nil
if we don't want to create a directory for it).  Simplify the code based
on the fact that (defvar V E) only evaluates E if V is not yet `boundp`.
(org-babel-temp-file, org-babel-temp-stable-file)
(org-babel-remove-temporary-directory)
(org-babel-remove-temporary-stable-directory): Adjust accordingly.

* lisp/org.el (org-log-beginning): Add FIXME.

* testing/org-test.el: Require `org` and `org-id`.
(org-id-locations-file): Don't `defconst` it.
(org-test-at-id, org-test-in-example-file, org-test-at-marker)
(org-test-with-temp-text, org-test-with-temp-text-in-file): Move edebug
specs into `declare` (and simplify them).
(org-test-with-tramp-remote-dir--worker): Declare dynbound tramp vars.
(org--compile-when): Fix quoting of `exp`.
(org-test-load): Tweak regexps.

* testing/org-batch-test-init.el: Tweak regexp, remove dead code and
add a FIXME about it.

* testing/lisp/test-ox.el: Require `ox` instead of
erroring out if it's not already loaded.  Also require `org-inlinetask`.
(org-test-with-parsed-data): Silence warnings when `info` is not used.
(test-org-export/bind-keyword): Add FIXME.

* testing/lisp/test-ox-publish.el: Require `org-test` and `ox-publish`.
(test-org-publish/resolve-external-link): Expose lambdas to
the compiler.  Remove unused var `ids`.
(test-org-publish/get-project-from-filename): Remove unused var `file`.

* testing/lisp/test-org.el: Require `org-macs`, `org`,
`org-inlinetask`, `org-refile`, and `org-agenda`.
(test-org/org-read-date): Declare `org-time-was-given` as dynbound.
(test-org/set-regexps-and-options): Add FIXME.

* testing/lisp/test-org-timer.el: Require `org-timer`.

* testing/lisp/test-org-table.el: Require `ox`.

* testing/lisp/test-org-protocol.el: Require `org-protocol` instead of
erroring out if it's not already loaded.  Also require `capture`, and
add missing `provide` statement.

* testing/lisp/test-org-pcomplete.el: Require `org`.

* testing/lisp/test-org-list.el: Require `org-list` and `org`.

* testing/lisp/test-org-lint.el: Require `org-footnote` and `org-lint`.

* testing/lisp/test-org-footnote.el: Require `org-footnote`.

* testing/lisp/test-org-element.el: Require `org-element` instead of
erroring out if it's not already loaded.  Also require `org` and
`org-inlinetask`.

* testing/lisp/test-org-duration.el: Require `org-duration`.

* testing/lisp/test-org-datetree.el: Require `org-datetree`.

* testing/lisp/test-org-colview.el: Require `org-colview`,
`org-duration`, and `org-inlinetask`.

* testing/lisp/test-org-clock.el: Require `org-duration` and `org-clock`.

* testing/lisp/test-org-archive.el: Require `org-archive`.

* testing/lisp/test-org-agenda.el
(test-org-agenda/bulk-custom-arg-func): Add FIXME.

* testing/lisp/test-ol.el: Require `ol` and `org-id`.
(test-org-link/store-link): Declare `org-store-link-props` and add FIXME.

* testing/lisp/test-oc.el (test-org-cite/export-capability): Add FIXME.

* testing/lisp/test-ob.el: Require `ob-core`, `org-src`, `ob-ref`,
and `org-table`.
(test-ob/eval-header-argument): Rename `foo` to `test-ob--foo` and
declare it as dynbound.
(test-ob/blocks-with-spaces, test-ob/specific-colnames): Add FIXME.
(test-ob/noweb-expansions-in-cache):
Declare `noweb-expansions-in-cache-var` as dynbound.

* testing/lisp/test-ob-tangle.el: Require `org` and `ob-tangle`.

* testing/lisp/test-ob-shell.el:
* testing/lisp/test-ob-python.el: Require `ob-core`.

* testing/lisp/test-ob-lob.el: Require `ob-lob`.
(temporary-value-for-test): Declare as dynbound.

Re: Use lexical-scoping in tests

[Stefan Monnier]

Ihor Radchenko [2022-09-14 20:32:53] wrote:
> Stefan Monnier  writes:
>> The patch below simply enables `lexical-binding` in all the test files.
>> As far as I can tell, it's all that's needed (beside a missing
>> `require`).
> Thanks, but the patch causes 23 tests to fail (running make test).

Oh, lord!

The fix is in preparation, but obviously I had tested my patch
incorrectly (i.e. I probably compiled and tested another code than the
one I had patched).

[ At least it explains why I was seeing this weird "it's all that's
  needed", which I always hope for but is so rarely true.  ]

> Also, is there any reason why it was a plain diff?

Lack of inspiration, mostly.


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

>> In my book step 3 above is a mistake (even if moved to step 2).
> I am confused.
> AFAIK, changing the load-path is a common way for users to install
> packages manually.

No, you're not confused, I just think that installing packages manually
(including messing with `load-path` and writing `(autoload ...)` in your
init file) is very last century :-)


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

>> Yup.  But there's no option to automatically find those dependencies in
>> ELisp, and (IIRC from last time I looked at it, in many packages obeying
>> such dependencies would end up introducing circular dependencies in
>> the Makefile), so we'd have to depend on the package's author to provide
>> a working set of file dependencies.
>
> It would be nice to have such an option.

Agreed.  The "last time" mentioned above, I looked at changing the
byte-compiler to keep track of the macros that were expanded so we can
auto-generate the dependencies.

> At least, for the most critical macros.  Something similar to
> declare statements.

But that also requires manual intervention :-(

>> Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
>> relegated to "late in the `load-path`" (i.e. after the directory that
>> holds the new-Org file) and should hence not be loaded any more (unless
>> someone goes through the trouble to explicitly load an old-Org files
>> with an absolute file name).
>
> I admit that I do not have sufficient knowledge about the autoload magic
> Emacs uses when loading packages.
>
> For reference, one simple way to trigger "mixed" state of Org is doing
> something like:
>
> 1. emacs -Q
> 2. (require 'org)
> 3. Add the newer Org version to load-path
> 4. (require 'ob-python)
>
> When and which version of org-autoloads.el will be loaded in
> such scenario?

None :-(

In my book step 3 above is a mistake (even if moved to step 2).

The `org-autoloads.el` is the file that adds the dir to `load-path`
(and in a normal ELPA install, that's the file that `package.el` loads
for you at startup).
So step 3 above is replaced by (load ".../org-autoloads"), and that's
where the problem would be detected.

But admittedly, that won't help users who made the mistake of
manually adding to `load-path` :-(


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

>> - git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
>> - make autoloads  =>  this refreshes the autoloads, but the .elc files
>>   of those .el files which didn't change still won't be recompiled.
>
> Isn't it a bug in the elpa scripts then?
> If a macro definition is changed and the .elc file using that macro is
> not changed, it still needs to be re-compiled. Otherwise, all kinds of
> unexpected side effects may appear.

Yup.  But there's no option to automatically find those dependencies in
ELisp, and (IIRC from last time I looked at it, in many packages obeying
such dependencies would end up introducing circular dependencies in
the Makefile), so we'd have to depend on the package's author to provide
a working set of file dependencies.

Note that the same problem applies to Emacs's own ELisp files.
In Emacs we have `make bootstrap` to manually get out of such
a bad compilation.

>> PPS: Maybe instead of calling `org-assert-version` everywhere, the
>>  `org-autoloads.el` (i.e. the file that sets up the `load-path` and
>>  the autoloads) could look for traces of Org files in the
>>  `load-history` and signal an error if such files are found coming
>>  from a different directory.
>
> No, unfortunately.
>
> org-autoloads, when loaded from built-in Emacs version will not help
> to catch newer Org libraries being loaded after built-in Org version is
> loaded.

Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
relegated to "late in the `load-path`" (i.e. after the directory that
holds the new-Org file) and should hence not be loaded any more (unless
someone goes through the trouble to explicitly load an old-Org files
with an absolute file name).

> Moreover, I consider loading personal forks of built-in Org libraries a
> valid use-case. Demanding all the org libraries to be loaded from the
> same directory will limit this possibility.

As long as they're loaded after new-org-autoloads.el, it would still be
fine since the test is only performed once when loading the
new-org-autoloads.el.


Stefan

Re: org-assert-version considered harmful

[Stefan Monnier]

Ihor Radchenko [2022-09-13 09:52:37] wrote:
> Stefan Monnier  writes:
>> I can see the reason for this macro, and I don't really have a better
>> solution to offer, but as someone who has a Git clone of Org that is
>> regularly updated using (basically) the normal compilation
>> system used in Emacs (i.e. not systematically recompiling all the files,
>> but only those whose `.el` is more recent than their `.elc`), it means
>> that whenever Org's version changes, I have to manually erase all the
>> `.elc` files otherwise this macro will (incorrectly)
>> complain everywhere  :-(
> Does it help if you run make autoloads after git fetch?

Not that I can tell, no.  But note that I'm not using Org's makefile to
compile the files, I'm using the elpa.git scripts instead, which don't
take into account dependencies between files.

So the situation is simply something like:

- git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
- make autoloads  =>  this refreshes the autoloads, but the .elc files
  of those .el files which didn't change still won't be recompiled.

I'm not really reporting a bug; I'm not sure how to solve the problem
without throwing away the benefits of `org-assert-version`.  But I just
wanted to mention that it has unintended side effects :-)


Stefan


PS: BTW, I notice that when Org is installed as a normal `package.el`
package, in Emacs≥28 it will be activated before the `.emacs` file
is loaded, which should prevent occurrence of the problems that
`org-assert-version` aims to catch (unless you use, say, an
org-babel file for the `early-init.el` :-)

PPS: Maybe instead of calling `org-assert-version` everywhere, the
 `org-autoloads.el` (i.e. the file that sets up the `load-path` and
 the autoloads) could look for traces of Org files in the
 `load-history` and signal an error if such files are found coming
 from a different directory.

Use lexical-scoping in tests

[Stefan Monnier]

The patch below simply enables `lexical-binding` in all the test files.
As far as I can tell, it's all that's needed (beside a missing
`require`).


Stefan
diff --git a/testing/examples/babel.el b/testing/examples/babel.el
index a7bb0ccf52..cbd522e243 100644
--- a/testing/examples/babel.el
+++ b/testing/examples/babel.el
@@ -1,3 +1,4 @@
+;; -*- lexical-binding: t; -*-
 (string-match-p "^#[[:digit:]]+$" "#123")
 
 ;; [[id:73115FB0-6565-442B-BB95-50195A499EF4][detangle:1]]
diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index 5f1dd1acb7..793ca31684 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -1,4 +1,4 @@
-;;; test-ob-C.el --- tests for ob-C.el
+;;; test-ob-C.el --- tests for ob-C.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov, Thierry Banel
 ;; Authors: Sergey Litvinov, Thierry Banel
diff --git a/testing/lisp/test-ob-R.el b/testing/lisp/test-ob-R.el
index 1e60ae903f..98d73dea91 100644
--- a/testing/lisp/test-ob-R.el
+++ b/testing/lisp/test-ob-R.el
@@ -1,4 +1,4 @@
-;;; test-ob-R.el --- tests for ob-R.el
+;;; test-ob-R.el --- tests for ob-R.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2011-2014, 2019 Eric Schulte
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-awk.el b/testing/lisp/test-ob-awk.el
index 21151b21fc..874d2c0268 100644
--- a/testing/lisp/test-ob-awk.el
+++ b/testing/lisp/test-ob-awk.el
@@ -1,4 +1,4 @@
-;;; test-ob-awk.el --- tests for ob-awk.el
+;;; test-ob-awk.el --- tests for ob-awk.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov
 ;; Authors: Sergey Litvinov
diff --git a/testing/lisp/test-ob-clojure.el b/testing/lisp/test-ob-clojure.el
index 609fc0ea85..3a21498b4a 100644
--- a/testing/lisp/test-ob-clojure.el
+++ b/testing/lisp/test-ob-clojure.el
@@ -1,4 +1,4 @@
-;;; test-ob-clojure.el
+;;; test-ob-clojure.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2018-2022 Free Software Foundation, Inc.
 ;; Authors: stardiviner
diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el
index e7b85d5ba5..c7bf17784b 100644
--- a/testing/lisp/test-ob-emacs-lisp.el
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -1,4 +1,4 @@
-;;; test-ob-emacs-lisp.el
+;;; test-ob-emacs-lisp.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2012-2022 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte, Martyn Jago
diff --git a/testing/lisp/test-ob-eshell.el b/testing/lisp/test-ob-eshell.el
index d74742690b..4430a21c7a 100644
--- a/testing/lisp/test-ob-eshell.el
+++ b/testing/lisp/test-ob-eshell.el
@@ -1,4 +1,4 @@
-;;; test-ob-eshell.el
+;;; test-ob-eshell.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2018 stardiviner
 ;; Authors: stardiviner
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index 1289745aea..b85db33401 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -1,4 +1,4 @@
-;;; test-ob-exp.el
+;;; test-ob-exp.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2015, 2019 Eric Schulte
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-fortran.el b/testing/lisp/test-ob-fortran.el
index 79a35d58e8..3f821e4dac 100644
--- a/testing/lisp/test-ob-fortran.el
+++ b/testing/lisp/test-ob-fortran.el
@@ -1,4 +1,4 @@
-;;; test-ob-fortran.el --- tests for ob-fortran.el
+;;; test-ob-fortran.el --- tests for ob-fortran.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2010-2014, 2019 Sergey Litvinov
 ;; Authors: Sergey Litvinov
diff --git a/testing/lisp/test-ob-header-arg-defaults.el b/testing/lisp/test-ob-header-arg-defaults.el
index 1106892d55..beb3ea5b8a 100644
--- a/testing/lisp/test-ob-header-arg-defaults.el
+++ b/testing/lisp/test-ob-header-arg-defaults.el
@@ -1,4 +1,4 @@
-;;; test-ob-header-arg-defaults.el --- tests for default header args from properties
+;;; test-ob-header-arg-defaults.el --- tests for default header args from properties  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2013, 2014, 2019 Achim Gratz
 ;; Authors: Achim Gratz
diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index 56ced23740..1a79fc66a1 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -1,4 +1,4 @@
-;;; test-ob-java.el --- tests for ob-java.el
+;;; test-ob-java.el --- tests for ob-java.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2020-2022 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte
diff --git a/testing/lisp/test-ob-julia.el b/testing/lisp/test-ob-julia.el
index f6d21726aa..b25235f5fa 100644
--- a/testing/lisp/test-ob-julia.el
+++ b/testing/lisp/test-ob-julia.el
@@ -1,4 +1,4 @@
-;;; test-ob-python.el --- tests for ob-python.el
+;;; test-ob-python.el --- tests for ob-python.el  -*- lexical-binding: t; -*-
 
 ;; Copyright (c) 2011-2014, 2019, 2021 Eric Schulte
 ;; Authors: Pedro Bruel, based on test-ob-python.el by Eric Schulte
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond

org-assert-version considered harmful

[Stefan Monnier]

I can see the reason for this macro, and I don't really have a better
solution to offer, but as someone who has a Git clone of Org that is
regularly updated using (basically) the normal compilation
system used in Emacs (i.e. not systematically recompiling all the files,
but only those whose `.el` is more recent than their `.elc`), it means
that whenever Org's version changes, I have to manually erase all the
`.elc` files otherwise this macro will (incorrectly)
complain everywhere  :-(


Stefan

Re: [External] : Re: missing a character / font in agenda?

[Stefan Kangas]

Ihor Radchenko  writes:

>>> I think this should be considered a bug, since the glyph used (LEFTWARDS
>>> TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts.

If that is true (I don't know) then maybe we should just use a more
ubiquitous glyph?

> The commit is supposed to fall back to ASCII symbol if the Unicode
> variant is not available, but apparently the check failed for some
> reason:
[...]
> Stefan, do you have any idea what can go wrong here?
>
> The only thing I can think about is warning in the char-displayable-p
> docstring:
>
> >> On a multi-font display, the test is only whether there is an
> >> appropriate font from the selected frame's fontset to display
> >> CHAR's charset in general.  Since fonts may be specified on a
> >> per-character basis, this may not be accurate.

I don't think we specify a particular font here, do we?  So it seems
like there might be a bug in Emacs here?  I'm not an expert on this
stuff by any means, but I would probably 'M-x report-emacs-bug' to
find out why 'char-displayable-p' would say that a character is
displayable when it's not.

[PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo.

[Stefan Kangas]

The attached patch fixes a small typo I found in the
`org-refile-targets' docstring.
From fe1c6f69ffcd3dfdb04c728f92e63e2fb1e4b4c0 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Wed, 13 Jul 2022 00:22:20 +0200
Subject: [PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo.

---
 lisp/org-refile.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index af1932687..01f0dfa46 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -95,7 +95,7 @@ You can set the variable `org-refile-target-verify-function' to a function
 to verify each headline found by the simple criteria above.
 
 When this variable is nil, all top-level headlines in the current buffer
-are used, equivalent to the value `((nil . (:level . 1))'."
+are used, equivalent to the value `((nil . (:level . 1)))'."
   :group 'org-refile
   :type '(repeat
 	  (cons
-- 
2.30.2

Re: fontsets

[Stefan Nobis]

Juan Manuel Macías  writes:

> [1] I have to add, by the way, that MatchLowercase is not always a
> panacea.

Hmmm... maybe add optional extra config/output option to the fontset,
like so:

┌
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│  (myfontb ...)
│  ...)
│ ;; Fontsets
│ ((myfontset .
│   ((sans . myfonta)
│(serif . myfontb)
│(mono . myfontc)
│(extra . ((lualatex . "\\defaultfontfeatures{Scale=MatchLowercase}")
│  (html "some CSS...")...))
│...))
│  ...)
└

This way it may be possible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.

-- 
Until the next mail...,
Stefan.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Juan Manuel Macías  writes:

> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

I would vote to activate this by default.

> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)

I would prefer to make it easier to stick with the default fonts. So
only add the font selection commands (including defaultfontfeatures)
when the font variables are non-nil. If no font has been explicitly
chosen, just use the default (in case of lualatex Latin Modern).

For me, it does not matter whether the 'org-latex-fontspec-*'
variables have a default of nil or set to the Free* fonts or something
else. For my configuration, I would set these variable to nil in order
to get the LaTeX default fonts and would like to go with the default
preamble of Org and then add to this on a per document basis.

This way, the whole configuration would be a little more composable, I
think.

-- 
Until the next mail...,
Stefan.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Ihor Radchenko  writes:

> But can someone check if Free* fonts are available on Windows and
> Mac by default?

I just checked TeXLive (on MacOS, but should be the same on all
systems): The Free* fonts are part of TeXLive as truetype and as
opentype versions (and partly in other formats).

For Windows I remember vaguely that some prefer the MikTeX
distribution (TeXLive is also available for Windows and has the same
fonts as everywhere). A short search shows that the gnu-freefont set
is also availabe for MikTeX, but I currently don't know whether it
will be installed with a default MikTeX installation.

> This unified preamble approach is consistent with what we do now.
> However, our currently used large preambles will slow down compilation.

Not that much. The time consuming packages like tikz/pgf (used by
beamer) are not part of out default preamble. There is not that much
speed to gain (all times are for a single lualatex run):

1) Only hyperref loaded, no other packages:
   0.46s user 0.10s system 99% cpu 0.568 total

2) Complete default preamble for lualatex:
   0.48s user 0.14s system 99% cpu 0.623 total

3) The same as above, but with babel and mathtools:
   0.51s user 0.15s system 99% cpu 0.673 total

4) And another variant (same as before, but package caption instead of
   capt-of):
   0.53s user 0.14s system 98% cpu 0.674 total

5) Back to our default preamble, but adding fontspec:
   0.60s user 0.14s system 99% cpu 0.748 total

6) With fontspec, unicode-math, babel, mathtools, caption:
   1.02s user 0.19s system 99% cpu 1.220 total

Therefore most of out default packages (and even the addition of
babel) does not change much for the speed of compilation. I don't
think its worth to try to further optimize this default preamble.

Adding fontspec and especially unicode-math adds quite some time, so
maybe its worth to take care to only add these if necessary (only for
lualatex/xelatex and only if e.g. if a font has been selected or math
seems to be used in the document).

And, by the way, our preamble is neither large nor complex. For my
LaTeX documents, the preamble is usually *much* larger. :)


Here is the test file for the default preamble (but with mathtools
instead of amsmath and with babel; test run 3):

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---


Here is the test file for the last run with all extra packages:

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage{fontspec}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage[warnings-off={mathtools-colon,mathtools-overbracket}]{unicode-math}
\usepackage{caption}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---



-- 
Until the next mail...,
Stefan.

[PATCH] Fix typos

[Stefan Kangas]

Please see the attached.
From 5ecf4e9613993a520844b78880bf57c04f193880 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Thu, 30 Jun 2022 17:33:03 +0200
Subject: [PATCH] ; Fix typos

---
 lisp/org-element.el  | 14 +++---
 lisp/org-fold-core.el| 10 +-
 lisp/org-persist.el  | 14 +++---
 lisp/org-src.el  |  2 +-
 lisp/org.el  |  2 +-
 lisp/ox-latex.el | 12 ++--
 lisp/ox-texinfo.el   |  2 +-
 testing/lisp/test-org-element.el |  2 +-
 testing/lisp/test-ox-publish.el  |  2 +-
 9 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 2a826bdbb..8964770f0 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -700,7 +700,7 @@ is cleared and contents are removed in the process."
;; DATUM is i.e. a headline, it's property list (`:title'
;; in case of headline) can contain parsed objects.  The
;; objects will contain `:parent' property set to the DATUM
-   ;; iteself.  When copied, these inner `:parent' propery
+   ;; itself.  When copied, these inner `:parent' propery
;; values will contain incorrect object decoupled from
;; DATUM.  Changes to the DATUM copy will not longer be
;; reflected in the `:parent' properties.  So, we need to
@@ -1289,7 +1289,7 @@ parser (e.g. `:end' and :END:).  Return value is a plist."
   (category (catch 'buffer-category
   (unless org-element-org-data-parser--recurse
 (org-with-point-at end
-  ;; Avoid recusrive calls from
+  ;; Avoid recursive calls from
   ;; `org-element-at-point-no-context'.
   (let ((org-element-org-data-parser--recurse t))
 	(while (re-search-backward "^[ \t]*#\\+CATEGORY:" (point-min) t)
@@ -6092,7 +6092,7 @@ completing the request."
 (log org-element--cache-size 2))
 (org-element-cache-reset)
 (throw 'org-element--cache-quit t)))
-  ;; Done deleting everthing starting before END.
+  ;; Done deleting everything starting before END.
   ;; DATA-KEY is the first known element after END.
   ;; Move on to phase 1.
   (org-element--cache-log-message
@@ -6664,7 +6664,7 @@ The function returns the new value of `org-element--cache-change-warning'."
  ;; `org-element--cache-submit-request').  After the edit, we want to
  ;; look if there was a sensitive removed during edit.
  ;; FIXME: This is not the most efficient way and we now
- ;; have to delete more elemetns than needed in some
+ ;; have to delete more elements than needed in some
  ;; cases.  A better approach may be storing the warning
  ;; in the modification request itself.
  (let ((org-element--cache-change-warning-before org-element--cache-change-warning)
@@ -6748,7 +6748,7 @@ that range.  See `after-change-functions' for more information."
   "This variable controls how buffer changes are handled by the cache.
 
 By default (when this variable is nil), cache re-parses modified
-headlines immidiately after modification preserving all the unaffected
+headlines immediately after modification preserving all the unaffected
 elements inside the headline.
 
 The default behaviour works best when users types inside Org buffer of
@@ -6870,7 +6870,7 @@ known element in cache (it may start after END)."
  ;; costly.  Instead, we should better re-parse only the
  ;; headline itself when possible.  If a headline is still
  ;; starting from old :begin position, we do not care that
- ;; its boundaries could have extended to shrinked - we
+ ;; its boundaries could have extended to shrunk - we
  ;; will re-parent and shift them anyway.
  (and (eq 'headline (org-element-type up))
   (not org-element--cache-avoid-synchronous-headline-re-parsing)
@@ -7154,7 +7154,7 @@ The element is: %S\n The real element is: %S\n Cache around :begin:\n%S\n%S\n%S"
(cdr (org-element--cache-find (org-element-property :begin real-element) 'both)))
   (org-element-cache-reset))
 
-;;; Cache persistance
+;;; Cache persistence
 
 (defun org-element--cache-persist-before-write (container  associated)
   "Sync cache before saving."
diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el
index 68a777de9..212fa09a8 100644
--- a/lisp/o

Re: [PATCH] Delete some Emacs 24 compat code

[Stefan Kangas]

Ihor Radchenko  writes:

> We usually put obsolete aliases into org-compat.el instead of sprinkling
> them across the various .el files. Please move the
> define-obsolete-function-alias statements to org-compat.

Thanks, please find attached an updated patch.
From aa0637c22ff1465a19d4007f1e9d16cc0df9972c Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Thu, 30 Jun 2022 13:06:21 +0200
Subject: [PATCH] Delete some Emacs 24 compat code

Org mode supports Emacs 26 or newer:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility

* lisp/org-compat.el (org-set-transient-map)
(org-font-lock-ensure): Delete compat aliases.  Update callers.
(org-define-error): Redefine as obsolete function alias for
`define-error'.  Update callers.
(string-suffix-p): Delete compatibility definition.

* lisp/org-fold-core.el (org-fold-core--seq-partition): Delete private
function and update callers to use `seq-partition'.

* lisp/org-macs.el (org-without-partial-completion): Move from here...
* lisp/org-compat.el (org-without-partial-completion): ...to here.
Redefine as obsolete function alias for `progn'.
---
 lisp/org-clock.el |  2 +-
 lisp/org-compat.el| 38 ++
 lisp/org-fold-core.el | 22 ++
 lisp/org-goto.el  |  2 +-
 lisp/org-macs.el  | 13 -
 lisp/org-src.el   |  2 +-
 lisp/org-table.el |  6 +++---
 lisp/org.el   |  4 ++--
 lisp/ox-html.el   |  2 +-
 lisp/ox-odt.el|  2 +-
 lisp/ox-org.el|  2 +-
 lisp/ox.el|  2 +-
 12 files changed, 16 insertions(+), 81 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 7d99e5087..e0b2d3ce6 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2122,7 +2122,7 @@ fontified, and then returned."
 (org-mode)
 (org-create-dblock props)
 (org-update-dblock)
-(org-font-lock-ensure)
+(font-lock-ensure)
 (forward-line 2)
 (buffer-substring (point) (progn
 (re-search-forward "^[ \t]*#\\+END" nil t)
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 10c125a2c..d8104e7e7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -904,12 +904,6 @@ context.  See the individual commands for more information."
 ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data))
  (w32-get-clipboard-data
 
-;; `set-transient-map' is only in Emacs >= 24.4
-(defalias 'org-set-transient-map
-  (if (fboundp 'set-transient-map)
-  'set-transient-map
-'set-temporary-overlay-map))
-
 
 ;;; Region compatibility
 
@@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'."
   string)
   (apply 'kill-new string args))
 
-;; `font-lock-ensure' is only available from 24.4.50 on
-(defalias 'org-font-lock-ensure
-  (if (fboundp 'font-lock-ensure)
-  #'font-lock-ensure
-(lambda ( _beg _end)
-  (with-no-warnings (font-lock-fontify-buffer)
-
 ;; `file-local-name' was added in Emacs 26.1.
 (defalias 'org-babel-local-file-name
   (if (fboundp 'file-local-name)
@@ -994,29 +981,8 @@ Pass COLUMN and FORCE to `move-to-column'."
(defun org-release () "N/A")
(defun org-git-version () "N/A !!check installation!!"))
 
-
-
-;;; Functions for Emacs < 24.4 compatibility
-
-(defun org-define-error (name message)
-  "Define NAME as a new error signal.
-MESSAGE is a string that will be output to the echo area if such
-an error is signaled without being caught by a `condition-case'.
-Implements `define-error' for older emacsen."
-  (if (fboundp 'define-error) (define-error name message)
-(put name 'error-conditions
- (copy-sequence (cons name (get 'error 'error-conditions))
-
-(unless (fboundp 'string-suffix-p)
-  ;; From Emacs subr.el.
-  (defun string-suffix-p (suffix string   ignore-case)
-"Return non-nil if SUFFIX is a suffix of STRING.
-If IGNORE-CASE is non-nil, the comparison is done without paying
-attention to case differences."
-(let ((start-pos (- (length string) (length suffix
-  (and (>= start-pos 0)
-   (eq t (compare-strings suffix nil nil
-  string start-pos nil ignore-case))
+(define-obsolete-function-alias 'org-define-error #'define-error "9.6")
+(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6")
 
 
 ;;; Integration with and fixes for other packages
diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el
index 88072852d..68a777de9 100644
--- a/lisp/org-fold-core.el
+++ b/lisp/org-fold-core.el
@@ -1304,25 +1304,7 @@ property, unfold the region if the :fragile function returns non-nil."
;; Move to next fold.
(setq pos (org-fold-core-next-folding-state-change spec pos local-to
 
-;;; Hanlding killing/yanking of folded text
-
-;; Backward compatibility 

[PATCH] Delete some Emacs 24 compat code

[Stefan Kangas]

The attached patch deletes some Emacs 24 compat code.  Org mode
supports Emacs 26 or later, according to:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
From 6e854576494f918c36cdd0ce698793574af494df Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Thu, 30 Jun 2022 13:06:21 +0200
Subject: [PATCH] Delete some Emacs 24 compat code

Org mode supports Emacs 26 or newer:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility

* lisp/org-compat.el (org-set-transient-map)
(org-font-lock-ensure): Delete compat aliases.  Update callers.
(org-define-error): Redefine as obsolete function alias for
`define-error'.  Update callers.
(string-suffix-p): Delete compatibility definition.
* lisp/org-fold-core.el (org-fold-core--seq-partition): Redefine
as obsolete function alias for `seq-partition'.  Update callers.
* lisp/org-macs.el (org-without-partial-completion): Redefine as
obsolete function alias for `progn'.
---
 lisp/org-clock.el |  2 +-
 lisp/org-compat.el| 37 +
 lisp/org-fold-core.el | 24 
 lisp/org-goto.el  |  2 +-
 lisp/org-macs.el  | 13 +
 lisp/org-src.el   |  2 +-
 lisp/org-table.el |  6 +++---
 lisp/org.el   |  4 ++--
 lisp/ox-html.el   |  2 +-
 lisp/ox-odt.el|  2 +-
 lisp/ox-org.el|  2 +-
 lisp/ox.el|  2 +-
 12 files changed, 18 insertions(+), 80 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 7d99e5087..e0b2d3ce6 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2122,7 +2122,7 @@ fontified, and then returned."
 (org-mode)
 (org-create-dblock props)
 (org-update-dblock)
-(org-font-lock-ensure)
+(font-lock-ensure)
 (forward-line 2)
 (buffer-substring (point) (progn
 (re-search-forward "^[ \t]*#\\+END" nil t)
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index baad39459..85f66587a 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -904,12 +904,6 @@ context.  See the individual commands for more information."
 ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data))
  (w32-get-clipboard-data
 
-;; `set-transient-map' is only in Emacs >= 24.4
-(defalias 'org-set-transient-map
-  (if (fboundp 'set-transient-map)
-  'set-transient-map
-'set-temporary-overlay-map))
-
 
 ;;; Region compatibility
 
@@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'."
   string)
   (apply 'kill-new string args))
 
-;; `font-lock-ensure' is only available from 24.4.50 on
-(defalias 'org-font-lock-ensure
-  (if (fboundp 'font-lock-ensure)
-  #'font-lock-ensure
-(lambda ( _beg _end)
-  (with-no-warnings (font-lock-fontify-buffer)
-
 ;; `file-local-name' was added in Emacs 26.1.
 (defalias 'org-babel-local-file-name
   (if (fboundp 'file-local-name)
@@ -994,29 +981,7 @@ Pass COLUMN and FORCE to `move-to-column'."
(defun org-release () "N/A")
(defun org-git-version () "N/A !!check installation!!"))
 
-
-
-;;; Functions for Emacs < 24.4 compatibility
-
-(defun org-define-error (name message)
-  "Define NAME as a new error signal.
-MESSAGE is a string that will be output to the echo area if such
-an error is signaled without being caught by a `condition-case'.
-Implements `define-error' for older emacsen."
-  (if (fboundp 'define-error) (define-error name message)
-(put name 'error-conditions
- (copy-sequence (cons name (get 'error 'error-conditions))
-
-(unless (fboundp 'string-suffix-p)
-  ;; From Emacs subr.el.
-  (defun string-suffix-p (suffix string   ignore-case)
-"Return non-nil if SUFFIX is a suffix of STRING.
-If IGNORE-CASE is non-nil, the comparison is done without paying
-attention to case differences."
-(let ((start-pos (- (length string) (length suffix
-  (and (>= start-pos 0)
-   (eq t (compare-strings suffix nil nil
-  string start-pos nil ignore-case))
+(define-obsolete-function-alias 'org-define-error #'define-error "9.6")
 
 
 ;;; Integration with and fixes for other packages
diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el
index 88072852d..287686c01 100644
--- a/lisp/org-fold-core.el
+++ b/lisp/org-fold-core.el
@@ -1304,25 +1304,9 @@ property, unfold the region if the :fragile function returns non-nil."
;; Move to next fold.
(setq pos (org-fold-core-next-folding-state-change spec pos local-to
 
-;;; Hanlding killing/yanking of folded text
-
-;; Backward compatibility with Emacs 24.
-(defun org-fold-core--seq-partition (list n)
-  "Return list of elements of LIST grouped into sub-sequences of length N.
-The last list may contain less than N elements.  If N is a
-negative integer or 0, nil is returned."
-  (if (fboundp 'seq-

Re: [PATCH] Improve "Speeding Up Your Agendas" chapters

[Stefan Kangas]

Ihor Radchenko  writes:

> Applied onto main via a722f6f8e with amendment to the commit message.

It seems like i bungled the patch: two typos are fixed in the attached.  Thanks.
From 29be11122821b18ffb56e109b4a9c457c65d1142 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Wed, 29 Jun 2022 15:01:09 +0200
Subject: [PATCH] * doc/org-manual.org (Speeding Up Your Agendas): Fix typos.

---
 doc/org-manual.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b7bb9570a..a4f5eee17 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21043,11 +21043,11 @@ number.  Here are tips to speed up:
   (setq org-agenda-use-tag-inheritance nil)
   #+end_src
 
-  #+vindex: org-agenda-ignore-drawer-properties
+  #+vindex: org-agenda-ignore-properties
 - Disable parsing of some drawer properties:
 
   #+begin_src emacs-lisp
-  (setq org-agenda-ignore-drawer-properties '(effort appt stats category))
+  (setq org-agenda-ignore-properties '(effort appt stats category))
   #+end_src
 
   The drawer properties you can disable in the agenda are effort
-- 
2.30.2

Re: [STYLE] :version tags in defcustom definitions (was: [PATCH] Improve look of agenda on graphical displays)

[Stefan Kangas]

Ihor Radchenko  writes:

> Sure. Just trying to clarify my confusion. The inconsistency with some
> defcustoms using :version and some not is bugging me.

Agreed.  It would be better to be consistent with this.

Re: Getting rid of org-install.el

[Stefan Kangas]

Kyle Meyer  writes:

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

Fine by me, though I don't think it's a very strong precedent; it
could be a one-off.

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?

Re: [PATCH] Improve look of agenda on graphical displays

[Stefan Kangas]

Ihor Radchenko  writes:

> >:group 'org-agenda
> > +  :version "29.1"
> > ...
> > -  :version "24.1"
> > +  :version "29.1"
> >:type 'string)
>
> I am wondering if this is meaningful considering that Org is not always
> distributed together with Emacs. Will this :version tag make any sense
> for people using the newest Org with older Emacs versions?

I think it won't really, but that's okay.  Also, this is how Org has
used these tags historically, try grepping for ":version" to see.

IOW, changing this is orthogonal to this patch.

Re: Getting rid of org-install.el

[Stefan Kangas]

Ihor Radchenko  writes:

> > 2. Delete the file from org-mode.git
> > ...
> > What do you think?
>
> Sounds good to me.

Patch attached.
From d609398f5a42a0157c309ead3e38be8ea78456f8 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Wed, 29 Jun 2022 05:36:47 +0200
Subject: [PATCH] * lisp/org-install.el: Delete file.

See: <https://lists.gnu.org/r/emacs-orgmode/2022-06/msg00822.html>
---
 lisp/org-install.el | 17 -
 1 file changed, 17 deletions(-)
 delete mode 100644 lisp/org-install.el

diff --git a/lisp/org-install.el b/lisp/org-install.el
deleted file mode 100644
index d521d819d..0
--- a/lisp/org-install.el
+++ /dev/null
@@ -1,17 +0,0 @@
-;;; org-install.el --- backward compatibility file for obsolete configuration  -*- lexical-binding: t -*-
-;;
-;;; Code:
-;;
-;; The file org-install is obsolete.
-;;
-;; It is provided here so that (require 'org-install) does not
-;; trigger an error for users with obsolete Emacs configuration.
-;; You can safely remove (require 'org-install) from your config."
-
-(provide 'org-install)
-
-;; Local Variables:
-;; no-byte-compile: t
-;; coding: utf-8
-;; End:
-;;; org-install.el ends here
-- 
2.30.2

Getting rid of org-install.el

[Stefan Kangas]

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

This means that all users (of old and new versions) will have a bundled
org-install.el so that requiring it still works, but on Emacs 29 or later
you will get the usual obsoletion warnings.  The file would finally be
removed from emacs.git in another decade or so according to current Emacs
maintenance practices.

What do you think?

[PATCH] Improve look of agenda on graphical displays

[Stefan Kangas]

The attached patch improves the look of the agenda time grid and
separator line on graphical displays.  It was inspired by
org-modern.el by Daniel Mendler.
From dba6d68019c74232f581a55ab012fd9d06f53434 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Mon, 27 Jun 2022 14:04:00 +0200
Subject: [PATCH] Improve look of agenda on graphical displays

* lisp/org-agenda.el (org-agenda-block-separator)
(org-agenda-time-grid, org-agenda-current-time-string): Improve
default visual elements on graphical displays.  Inspired by
org-modern.el by Daniel Mendler .
---
 lisp/org-agenda.el | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a66d6e116..495fd5454 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -131,13 +131,18 @@ name and week number or the separator lines."
   :group 'org-agenda
   :type 'boolean)
 
-(defcustom org-agenda-block-separator ?=
+(defcustom org-agenda-block-separator
+  (if (and (display-graphic-p)
+   (char-displayable-p ?─))
+  ?─
+?=)
   "The separator between blocks in the agenda.
 If this is a string, it will be used as the separator, with a newline added.
 If it is a character, it will be repeated to fill the window width.
 If nil the separator is disabled.  In `org-agenda-custom-commands' this
 addresses the separator between the current and the previous block."
   :group 'org-agenda
+  :version "29.1"
   :type '(choice
 	  (const :tag "Disabled" nil)
 	  (character)
@@ -1539,11 +1544,12 @@ the variable `org-agenda-time-grid'."
   :type 'boolean)
 
 (defcustom org-agenda-time-grid
-  '((daily today require-timed)
-(800 1000 1200 1400 1600 1800 2000)
-".."
-"")
-
+  (let ((graphical (and (display-graphic-p)
+(char-displayable-p ?┄
+`((daily today require-timed)
+  (800 1000 1200 1400 1600 1800 2000)
+  ,(if graphical " ┄ " "..")
+  ,(if graphical "┄┄┄" "")))
   "The settings for time grid for agenda display.
 This is a list of four items.  The first item is again a list.  It contains
 symbols specifying conditions when the grid should be displayed:
@@ -1563,6 +1569,7 @@ times that have a grid line.
 The fourth item is a string placed after the grid times.  This
 will align with agenda items."
   :group 'org-agenda-time-grid
+  :version "29.1"
   :type
   '(list
 (set :greedy t :tag "Grid Display Options"
@@ -1584,10 +1591,14 @@ will align with agenda items."
   :type 'boolean)
 
 (defcustom org-agenda-current-time-string
-  "now - - - - - - - - - - - - - - - - - - - - - - - - -"
+  (if (and (display-graphic-p)
+   (char-displayable-p ?⭠)
+   (char-displayable-p ?─))
+  "⭠ now ───"
+"now - - - - - - - - - - - - - - - - - - - - - - - - -")
   "The string for the current time marker in the agenda."
   :group 'org-agenda-time-grid
-  :version "24.1"
+  :version "29.1"
   :type 'string)
 
 (defgroup org-agenda-sorting nil
-- 
2.30.2

Re: [PATCH] Improve "Speeding Up Your Agendas" chapters

[Stefan Kangas]

Stefan Kangas  writes:

> > >  These options can be applied to selected agenda views.  For more
> > >  details about generation of agenda views, see the docstrings for the
> > >  relevant variables, and this 
> > > [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg 
> > > page]] for agenda
> >   ^ (missing trailing ".")

Note that the "." is on the next line (you can't see it in the patch though).

> Thanks, I'll update the patch.

Please see the attached.
From 34912156ef5e10ad435be7aa7fbb5025124f481a Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Jun 2022 13:07:46 +0200
Subject: [PATCH] Document org-agenda-ignore-properties in manual

* doc/org-manual.org (Speeding Up Your Agendas): Document
org-agenda-ignore-properties.
---
 doc/org-manual.org | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4c2e968e7..1926329ac 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21041,6 +21041,17 @@ number.  Here are tips to speed up:
   (setq org-agenda-use-tag-inheritance nil)
   #+end_src
 
+  #+vindex: org-agenda-ignore-drawer-properties
+- Disable parsing of some drawer properties:
+
+  #+begin_src emacs-lisp
+  (setq org-agenda-ignore-drawer-properties '(effort appt stats category))
+  #+end_src
+
+  The drawer properties you can disable in the agenda are effort
+  estimates (~effort~), appointments (~appt~), statistics (~stats~)
+  and subtree-local categories (~category~).
+
 These options can be applied to selected agenda views.  For more
 details about generation of agenda views, see the docstrings for the
 relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda
-- 
2.30.2

Re: [PATCH] Improve "Speeding Up Your Agendas" chapters

[Stefan Kangas]

Ihor Radchenko  writes:

> Does it have to be inside the main chapters of the manual?
> I really hope that users do not _normally_ have to know about these
> tricks.

I've never needed it, FWIW.

However, it also feels misplaced among the appendixes.  I guess this
is subjective: I prefer chapters that deal exhaustively with their
topic.

> > Subject: [PATCH 2/2] Document org-agenda-ignore-drawer-properties in manual
> >
> > * doc/org-manual.org (Speeding Up Your Agendas): Document
> > org-agenda-ignore-drawer-properties.
>
> Note that org-agenda-ignore-drawer-properties is obsolete.
>
> >  These options can be applied to selected agenda views.  For more
> >  details about generation of agenda views, see the docstrings for the
> >  relevant variables, and this 
> > [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] 
> > for agenda
>   ^ (missing trailing ".")

Thanks, I'll update the patch.

[PATCH] Improve "Speeding Up Your Agendas" chapters

[Stefan Kangas]

Please see the attached patches.  Thanks.
From 061255f1d6441f1496a3b062d6f29193ff2fb3c2 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Jun 2022 12:48:06 +0200
Subject: [PATCH 1/2] Move appendix on performance in manual to agenda chapter

* doc/org-manual.org (Speeding Up Your Agendas): Move section to
chapter "Agenda Views".
---
 doc/org-manual.org | 86 +++---
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4c2e968e7..6bedeb344 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10738,6 +10738,49 @@ environment.  This causes the following issues:
today, with the time already spent---via =CLOCKSUM=---and with
the planned total effort for it.
 
+** Speeding Up Your Agendas
+:PROPERTIES:
+:DESCRIPTION: Tips on how to speed up your agendas.
+:END:
+#+cindex: agenda views, optimization
+
+Some agenda commands slow down when the Org files grow in size or
+number.  Here are tips to speed up:
+
+- Reduce the number of Org agenda files to avoid slowdowns due to hard drive
+  accesses.
+
+- Reduce the number of DONE and archived headlines so agenda
+  operations that skip over these can finish faster.
+
+- Do not dim blocked tasks:
+  #+vindex: org-agenda-dim-blocked-tasks
+
+  #+begin_src emacs-lisp
+  (setq org-agenda-dim-blocked-tasks nil)
+  #+end_src
+
+- Stop preparing agenda buffers on startup:
+  #+vindex: org-startup-folded
+  #+vindex: org-agenda-inhibit-startup
+
+  #+begin_src emacs-lisp
+  (setq org-agenda-inhibit-startup t)
+  #+end_src
+
+- Disable tag inheritance for agendas:
+  #+vindex: org-agenda-show-inherited-tags
+  #+vindex: org-agenda-use-tag-inheritance
+
+  #+begin_src emacs-lisp
+  (setq org-agenda-use-tag-inheritance nil)
+  #+end_src
+
+These options can be applied to selected agenda views.  For more
+details about generation of agenda views, see the docstrings for the
+relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda
+optimization.
+
 * Markup for Rich Contents
 :PROPERTIES:
 :DESCRIPTION: Compose beautiful documents.
@@ -21003,49 +21046,6 @@ special function:
 (org-agenda-overriding-header "Projects waiting for something: "
 #+end_src
 
-** Speeding Up Your Agendas
-:PROPERTIES:
-:DESCRIPTION: Tips on how to speed up your agendas.
-:END:
-#+cindex: agenda views, optimization
-
-Some agenda commands slow down when the Org files grow in size or
-number.  Here are tips to speed up:
-
-- Reduce the number of Org agenda files to avoid slowdowns due to hard drive
-  accesses.
-
-- Reduce the number of DONE and archived headlines so agenda
-  operations that skip over these can finish faster.
-
-- Do not dim blocked tasks:
-  #+vindex: org-agenda-dim-blocked-tasks
-
-  #+begin_src emacs-lisp
-  (setq org-agenda-dim-blocked-tasks nil)
-  #+end_src
-
-- Stop preparing agenda buffers on startup:
-  #+vindex: org-startup-folded
-  #+vindex: org-agenda-inhibit-startup
-
-  #+begin_src emacs-lisp
-  (setq org-agenda-inhibit-startup t)
-  #+end_src
-
-- Disable tag inheritance for agendas:
-  #+vindex: org-agenda-show-inherited-tags
-  #+vindex: org-agenda-use-tag-inheritance
-
-  #+begin_src emacs-lisp
-  (setq org-agenda-use-tag-inheritance nil)
-  #+end_src
-
-These options can be applied to selected agenda views.  For more
-details about generation of agenda views, see the docstrings for the
-relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda
-optimization.
-
 ** Extracting Agenda Information
 :PROPERTIES:
 :DESCRIPTION: Post-processing agenda information.
-- 
2.30.2

From f6a192e912c32406829f734cb7fe95b47eea5af6 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Jun 2022 13:07:46 +0200
Subject: [PATCH 2/2] Document org-agenda-ignore-drawer-properties in manual

* doc/org-manual.org (Speeding Up Your Agendas): Document
org-agenda-ignore-drawer-properties.
---
 doc/org-manual.org | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6bedeb344..914f8db5d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10776,6 +10776,17 @@ number.  Here are tips to speed up:
   (setq org-agenda-use-tag-inheritance nil)
   #+end_src
 
+  #+vindex: org-agenda-ignore-drawer-properties
+- Disable parsing of some drawer properties:
+
+  #+begin_src emacs-lisp
+  (setq org-agenda-ignore-drawer-properties '(effort appt stats category))
+  #+end_src
+
+  The drawer properties you can disable in the agenda are effort
+  estimates (~effort~), appointments (~appt~), statistics (~stats~)
+  and subtree-local categories (~category~).
+
 These options can be applied to selected agenda views.  For more
 details about generation of agenda views, see the docstrings for the
 relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Wo

[PATCH] Add missing commands to org-agenda-custom-commands docstring

[Stefan Kangas]

It seems like the `org-agenda-custom-commands' docstring had some
missing and incorrect information.  Please see the attached patch that
should improve the situation slightly.
From 72dd496e5eba7310854caa6c6daaee2cebd62662 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Jun 2022 04:14:54 +0200
Subject: [PATCH] Add missing commands to org-agenda-custom-commands docstring

* lisp/org-agenda.el (org-agenda-custom-commands): Add missing
commands.  Add crossreference to the Info manual.
---
 lisp/org-agenda.el | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 67d97cd38..769ac0d45 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -462,10 +462,11 @@ agenda dispatcher `\\[org-agenda]'.  Each entry is a list like this:
 
 key  The key (one or more characters as a string) to be associated
  with the command.
-desc A description of the command, when omitted or nil, a default
+desc A description of the command.  When omitted or nil, a default
  description is built using MATCH.
 type The command type, any of the following symbols:
   agenda  The daily/weekly agenda.
+  agenda* Appointments for current week/day.
   todoEntries with a specific TODO keyword, in all agenda files.
   search  Entries containing search words entry or headline.
   tagsTags/Property/TODO match in all agenda files.
@@ -473,6 +474,8 @@ type The command type, any of the following symbols:
   todo-tree   Sparse tree of specific TODO keyword in *current* file.
   tags-tree   Sparse tree with all tags matches in *current* file.
   occur-tree  Occur sparse tree for *current* file.
+  alltodo The global TODO list.
+  stuck   Stuck projects.
   ... A user-defined function.
 matchWhat to search for:
   - a single keyword for TODO keyword searches
@@ -486,7 +489,7 @@ settings  A list of option settings, similar to that in a let form, so like
 files A list of files to write the produced agenda buffer to with
   the command `org-store-agenda-views'.
   If a file name ends in \".html\", an HTML version of the buffer
-  is written out.  If it ends in \".ps\", a postscript version is
+  is written out.  If it ends in \".ps\", a PostScript version is
   produced.  Otherwise, only the plain text is written to the file.
 
 You can also define a set of commands, to create a composite agenda buffer.
@@ -498,9 +501,9 @@ where
 
 desc   A description string to be displayed in the dispatcher menu.
 cmdAn agenda command, similar to the above.  However, tree commands
-   are not allowed, but instead you can get agenda and global todo list.
-   So valid commands for a set are:
+   are not allowed.  Valid commands for a set are:
(agenda \"\" settings)
+   (agenda* \"\" settings)
(alltodo \"\" settings)
(stuck \"\" settings)
(todo \"match\" settings files)
@@ -520,7 +523,9 @@ should provide a description for the prefix, like
\\='((\"h\" . \"HOME + Name tag searches\") ; describe prefix \"h\"
  (\"hl\" tags \"+HOME+Lisa\")
  (\"hp\" tags \"+HOME+Peter\")
- (\"hk\" tags \"+HOME+Kim\")))"
+ (\"hk\" tags \"+HOME+Kim\")))
+
+See also Info node `(org) Custom Agenda Views'."
   :group 'org-agenda-custom-commands
   :type `(repeat
 	  (choice :value ("x" "Describe command here" tags "" nil)
-- 
2.30.2

Re: [PATCH] Prefer "website" to "homepage"

[Stefan Kangas]

Ihor Radchenko  writes:

> Thanks! So, Emacs now advises to use "website" and "URL:", right?
> Mentioning this fact, and the relevant commit would improve the commit
> message. (that is: please update the commit message explaining the
> change by changed Emacs recommendations).

Please see the attached.
From cdd375813263250fd39be9888b3d0a68d9ba0063 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Sep 2021 09:44:29 +0200
Subject: [PATCH] Prefer "website" to "homepage"

Emacs now advises using "website" (instead of "homepage") and
consequently to use the "URL" comment header instead of "Homepage".

* README:
* README_ELPA:
* doc/org-guide.org (Creating Footnotes):
* doc/org-manual.org (Creating Footnotes):
* etc/styles/README (URL): Prefer "website" to "homepage".

* lisp/*.el:
* mk/org-fixup.el: Replace the "Homepage" header comment with "URL".
---
 README_ELPA|  2 +-
 doc/org-guide.org  |  2 +-
 doc/org-manual.org |  4 ++--
 etc/styles/README  |  2 +-
 lisp/ob-C.el   |  2 +-
 lisp/ob-R.el   |  2 +-
 lisp/ob-awk.el |  2 +-
 lisp/ob-calc.el|  2 +-
 lisp/ob-clojure.el |  2 +-
 lisp/ob-comint.el  |  2 +-
 lisp/ob-core.el|  2 +-
 lisp/ob-css.el |  2 +-
 lisp/ob-ditaa.el   |  2 +-
 lisp/ob-dot.el |  2 +-
 lisp/ob-emacs-lisp.el  |  2 +-
 lisp/ob-eshell.el  |  2 +-
 lisp/ob-eval.el|  2 +-
 lisp/ob-exp.el |  2 +-
 lisp/ob-forth.el   |  2 +-
 lisp/ob-fortran.el |  2 +-
 lisp/ob-gnuplot.el |  2 +-
 lisp/ob-groovy.el  |  2 +-
 lisp/ob-haskell.el |  2 +-
 lisp/ob-java.el|  2 +-
 lisp/ob-js.el  |  2 +-
 lisp/ob-julia.el   |  2 +-
 lisp/ob-latex.el   |  2 +-
 lisp/ob-lilypond.el|  2 +-
 lisp/ob-lisp.el|  2 +-
 lisp/ob-lob.el |  2 +-
 lisp/ob-lua.el |  2 +-
 lisp/ob-makefile.el|  2 +-
 lisp/ob-matlab.el  |  2 +-
 lisp/ob-maxima.el  |  2 +-
 lisp/ob-ocaml.el   |  2 +-
 lisp/ob-octave.el  |  2 +-
 lisp/ob-org.el |  2 +-
 lisp/ob-perl.el|  2 +-
 lisp/ob-plantuml.el|  2 +-
 lisp/ob-processing.el  |  2 +-
 lisp/ob-python.el  |  2 +-
 lisp/ob-ref.el |  2 +-
 lisp/ob-ruby.el|  2 +-
 lisp/ob-sass.el|  2 +-
 lisp/ob-scheme.el  |  2 +-
 lisp/ob-screen.el  |  2 +-
 lisp/ob-shell.el   |  2 +-
 lisp/ob-sql.el |  2 +-
 lisp/ob-sqlite.el  |  2 +-
 lisp/ob-table.el   |  2 +-
 lisp/ob-tangle.el  |  2 +-
 lisp/ob.el |  2 +-
 lisp/ol-bbdb.el|  2 +-
 lisp/ol-docview.el |  2 +-
 lisp/ol-eww.el |  2 +-
 lisp/ol-gnus.el|  2 +-
 lisp/ol-info.el|  2 +-
 lisp/ol-man.el |  2 +-
 lisp/ol-mhe.el |  2 +-
 lisp/ol-rmail.el   |  2 +-
 lisp/ol-w3m.el |  2 +-
 lisp/org-agenda.el |  2 +-
 lisp/org-archive.el|  2 +-
 lisp/org-capture.el|  2 +-
 lisp/org-clock.el  |  2 +-
 lisp/org-colview.el|  2 +-
 lisp/org-compat.el |  2 +-
 lisp/org-cycle.el  |  2 +-
 lisp/org-datetree.el   |  2 +-
 lisp/org-element.el|  2 +-
 lisp/org-entities.el   |  2 +-
 lisp/org-faces.el  |  2 +-
 lisp/org-feed.el   |  2 +-
 lisp/org-fold-core.el  |  2 +-
 lisp/org-fold.el   |  2 +-
 lisp/org-footnote.el   |  2 +-
 lisp/org-habit.el  |  2 +-
 lisp/org-id.el |  2 +-
 lisp/org-indent.el |  2 +-
 lisp/org-inlinetask.el |  2 +-
 lisp/org-list.el   |  2 +-
 lisp/org-macs.el   |  2 +-
 lisp/org-mobile.el |  2 +-
 lisp/org-pcomplete.el  |  2 +-
 lisp/org-plot.el   |  2 +-
 lisp/org-src.el|  2 +-
 lisp/org-table.el  |  2 +-
 lisp/org-tempo.el  |  2 +-
 lisp/org-timer.el  |  2 +-
 lisp/org.el| 10 +-
 lisp/ox-icalendar.el   |  2 +-
 lisp/ox-odt.el |  2 +-
 mk/org-fixup.el|  2 +-
 93 files changed, 98 insertions(+), 98 deletions(-)

diff --git a/README_ELPA b/README_ELPA
index c1ff5e282..c916fbe75 100644
--- a/README_ELPA
+++ b/README_ELPA
@@ -1,6 +1,6 @@
 This is the Emacs Org project, an Emacs library for organizing your life.
 
-The homepage of Org is at:
+The Org website is at:
   https://orgmode.org
 
 Installations instructions are at:
diff --git a/doc/org-guide.org b/doc/org-guide.org
index 4d53e4bfb..e23b2efa7 100644
--- a/doc/org-guide.org
+++ b/doc/org-guide.org
@@ -2066,7 +2066,7 @@ footnote reference is simply the marker in square brackets, inside
 text.  For example:
 
 #+begin_example
-The Org homepage[fn:1] now looks a lot better than it used to.
+The Org website[fn:1] now looks a lot better than it used to.
 ...
 [fn:1] The link is: https://orgmode.org
 #+end_example
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 0bf018077..4c2e968e7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11346,7 +11346,7 @@ footnote reference is simply 

[PATCH] Avoid treating a number as an enum in manual

[Stefan Kangas]

In "(org) Agenda Dispatcher", we have the following incorrect part:

  A prefix argument can be used
to specify the number of context lines for each match, default is
@enumerate
@item
@end enumerate

The attached patch should fix this.
From 68d4a3760535666fc69534a6f79ec3501626695f Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Fri, 24 Jun 2022 19:16:30 +0200
Subject: [PATCH] Avoid treating a number as an enum in manual

* doc/org-manual.org (The Agenda Dispatcher): Avoid treating
number as enum.
---
 doc/org-manual.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 07f151837..7c78110ef 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -8557,8 +8557,8 @@ commands:
   Search for a regular expression in all agenda files and additionally
   in the files listed in ~org-agenda-text-search-extra-files~.  This
   uses the Emacs command ~multi-occur~.  A prefix argument can be used
-  to specify the number of context lines for each match, default is
-  1.
+  to specify the number of context lines for each match, the default
+  is 1.
 
 - {{{kbd(#)}}} ::
 
-- 
2.30.2

[PATCH] Improve docstrings of agenda date navigation commands

[Stefan Kangas]

I found the docstrings of the agenda date navigation commands to be
somewhat lacking.  The attached patch expands them slightly and adds
crossreferences, which I think makes them much more usable.  Thanks.


0001-Improve-docstrings-of-agenda-date-navigation-command.patch
Description: Binary data

Re: [PATCH] Prefer "website" to "homepage"

[Stefan Kangas]

Ihor Radchenko  writes:

> > ... Emacs was recently
> > updated to list the "URL" header comment before "Homepage".
>
> Could you please point out to the relevant discussion?

This was uncontroversial so not really discussed, but see:

https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commit;h=bcf59b99f43be4f

[PATCH] Prefer "website" to "homepage"

[Stefan Kangas]

These days, a "home page" is understood to be only "the main web page
of a website" or "landing page", whereas a "website" is "a collection
of web pages and related content" (Wikipedia).  Emacs was recently
updated to list the "URL" header comment before "Homepage".

Please see the attached patch.
From 56ffe1256c4bdcc48d465c536c5bedcdb94d341e Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Sep 2021 09:44:29 +0200
Subject: [PATCH] Prefer "website" to "homepage"

These days, a "home page" is understood to be only "the main web page
of a website" or "landing page", whereas a "website" is "a collection
of web pages and related content" (Wikipedia).  Emacs was recently
updated to list the "URL" header comment before "Homepage".

* README:
* README_ELPA:
* doc/org-guide.org (Creating Footnotes):
* doc/org-manual.org (Creating Footnotes):
* etc/styles/README (URL): Prefer "website" to "homepage".

* lisp/*.el:
* mk/org-fixup.el: Replace the "Homepage" header comment with "URL".
---
 README_ELPA|  2 +-
 doc/org-guide.org  |  2 +-
 doc/org-manual.org |  4 ++--
 etc/styles/README  |  2 +-
 lisp/ob-C.el   |  2 +-
 lisp/ob-R.el   |  2 +-
 lisp/ob-awk.el |  2 +-
 lisp/ob-calc.el|  2 +-
 lisp/ob-clojure.el |  2 +-
 lisp/ob-comint.el  |  2 +-
 lisp/ob-core.el|  2 +-
 lisp/ob-css.el |  2 +-
 lisp/ob-ditaa.el   |  2 +-
 lisp/ob-dot.el |  2 +-
 lisp/ob-emacs-lisp.el  |  2 +-
 lisp/ob-eshell.el  |  2 +-
 lisp/ob-eval.el|  2 +-
 lisp/ob-exp.el |  2 +-
 lisp/ob-forth.el   |  2 +-
 lisp/ob-fortran.el |  2 +-
 lisp/ob-gnuplot.el |  2 +-
 lisp/ob-groovy.el  |  2 +-
 lisp/ob-haskell.el |  2 +-
 lisp/ob-java.el|  2 +-
 lisp/ob-js.el  |  2 +-
 lisp/ob-julia.el   |  2 +-
 lisp/ob-latex.el   |  2 +-
 lisp/ob-lilypond.el|  2 +-
 lisp/ob-lisp.el|  2 +-
 lisp/ob-lob.el |  2 +-
 lisp/ob-lua.el |  2 +-
 lisp/ob-makefile.el|  2 +-
 lisp/ob-matlab.el  |  2 +-
 lisp/ob-maxima.el  |  2 +-
 lisp/ob-ocaml.el   |  2 +-
 lisp/ob-octave.el  |  2 +-
 lisp/ob-org.el |  2 +-
 lisp/ob-perl.el|  2 +-
 lisp/ob-plantuml.el|  2 +-
 lisp/ob-processing.el  |  2 +-
 lisp/ob-python.el  |  2 +-
 lisp/ob-ref.el |  2 +-
 lisp/ob-ruby.el|  2 +-
 lisp/ob-sass.el|  2 +-
 lisp/ob-scheme.el  |  2 +-
 lisp/ob-screen.el  |  2 +-
 lisp/ob-shell.el   |  2 +-
 lisp/ob-sql.el |  2 +-
 lisp/ob-sqlite.el  |  2 +-
 lisp/ob-table.el   |  2 +-
 lisp/ob-tangle.el  |  2 +-
 lisp/ob.el |  2 +-
 lisp/ol-bbdb.el|  2 +-
 lisp/ol-docview.el |  2 +-
 lisp/ol-eww.el |  2 +-
 lisp/ol-gnus.el|  2 +-
 lisp/ol-info.el|  2 +-
 lisp/ol-man.el |  2 +-
 lisp/ol-mhe.el |  2 +-
 lisp/ol-rmail.el   |  2 +-
 lisp/ol-w3m.el |  2 +-
 lisp/org-agenda.el |  2 +-
 lisp/org-archive.el|  2 +-
 lisp/org-capture.el|  2 +-
 lisp/org-clock.el  |  2 +-
 lisp/org-colview.el|  2 +-
 lisp/org-compat.el |  2 +-
 lisp/org-cycle.el  |  2 +-
 lisp/org-datetree.el   |  2 +-
 lisp/org-element.el|  2 +-
 lisp/org-entities.el   |  2 +-
 lisp/org-faces.el  |  2 +-
 lisp/org-feed.el   |  2 +-
 lisp/org-fold-core.el  |  2 +-
 lisp/org-fold.el   |  2 +-
 lisp/org-footnote.el   |  2 +-
 lisp/org-habit.el  |  2 +-
 lisp/org-id.el |  2 +-
 lisp/org-indent.el |  2 +-
 lisp/org-inlinetask.el |  2 +-
 lisp/org-list.el   |  2 +-
 lisp/org-macs.el   |  2 +-
 lisp/org-mobile.el |  2 +-
 lisp/org-pcomplete.el  |  2 +-
 lisp/org-plot.el   |  2 +-
 lisp/org-src.el|  2 +-
 lisp/org-table.el  |  2 +-
 lisp/org-tempo.el  |  2 +-
 lisp/org-timer.el  |  2 +-
 lisp/org.el| 10 +-
 lisp/ox-icalendar.el   |  2 +-
 lisp/ox-odt.el |  2 +-
 mk/org-fixup.el|  2 +-
 93 files changed, 98 insertions(+), 98 deletions(-)

diff --git a/README_ELPA b/README_ELPA
index c1ff5e282..c916fbe75 100644
--- a/README_ELPA
+++ b/README_ELPA
@@ -1,6 +1,6 @@
 This is the Emacs Org project, an Emacs library for organizing your life.
 
-The homepage of Org is at:
+The Org website is at:
   https://orgmode.org
 
 Installations instructions are at:
diff --git a/doc/org-guide.org b/doc/org-guide.org
index 4d53e4bfb..e23b2efa7 100644
--- a/doc/org-guide.org
+++ b/doc/org-guide.org
@@ -2066,7 +2066,7 @@ footnote reference is simply the marker in square brackets, inside
 text.  For example:
 
 #+begin_example
-The Org homepage[fn:1] now looks a lot better than it used to.
+The Org website[fn:1] now looks a lot better than it used to.
 ...
 [fn:1] The link is: https://orgmode.org
 #+e

Re: [PATCH] Remove XEmacs and ancient Emacs compat code

[Stefan Kangas]

Ihor Radchenko  writes:

> Stefan Kangas  writes:
>
> > The attached patch removes some compat code for XEmacs, and Emacs 21/22.
>
> Thanks! And sorry for the late reply.
> The patch does not apply onto current main anymore.
> Would you mind updating the patch?

Please see the attached.
From 58a7d4275e2bdff7359ba3ac7b8d89a859d0c242 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 26 Sep 2021 21:29:25 +0200
Subject: [PATCH] Remove XEmacs and ancient Emacs compat code

* lisp/org-colview.el (org-columns-remove-overlays):
* lisp/org-ctags.el (org-ctags-find-tag-interactive):
* lisp/org-macs.el (org-fit-window-to-buffer):
* lisp/org-mouse.el (org-mouse-show-context-menu):
* lisp/org-table.el (org-table-fedit-lisp-indent):
* lisp/org.el (org-version, org-reload):
* lisp/ox-html.el (org-html-template, org-html--build-meta-info):
Remove Emacs 21 and 22 compat code.

* lisp/ol-eww.el (org-eww-copy-for-org-mode):
* lisp/ol-w3m.el (org-w3m-copy-for-org-mode):
* lisp/org-clock.el (org-clock-select-task):
* lisp/org-macs.el (org-fit-window-to-buffer):
* lisp/org-refile.el (org-refile):
* lisp/org.el (org-change-tag-in-region): Remove XEmacs compat code.

* lisp/org-goto.el (org-goto--set-map):
* lisp/org-macs.el (org-fit-window-to-buffer):
* lisp/org-table.el (orgtbl-mode):
* lisp/org.el (org-setup-filling): Remove XEmacs or Emacs 19 or 20
compat code.  (It is one of these; not clear which.)
---
 lisp/ol-eww.el   |  2 +-
 lisp/ol-w3m.el   |  2 +-
 lisp/org-clock.el|  1 -
 lisp/org-colview.el  |  3 +--
 lisp/org-ctags.el|  5 +
 lisp/org-goto.el |  6 ++
 lisp/org-macs.el | 13 ++---
 lisp/org-mouse.el|  5 +
 lisp/org-protocol.el |  1 +
 lisp/org-refile.el   |  2 +-
 lisp/org-table.el| 12 
 lisp/org.el  | 19 ---
 lisp/ox-html.el  |  3 +--
 13 files changed, 28 insertions(+), 46 deletions(-)

diff --git a/lisp/ol-eww.el b/lisp/ol-eww.el
index 23ba8b377..722e2c716 100644
--- a/lisp/ol-eww.el
+++ b/lisp/ol-eww.el
@@ -107,7 +107,7 @@ keep the structure of the Org file."
   (setq transform-start (region-beginning))
   (setq transform-end (region-end))
   ;; Deactivate mark if current mark is activate.
-  (when (fboundp 'deactivate-mark) (deactivate-mark)))
+  (deactivate-mark))
 (message "Transforming links...")
 (save-excursion
   (goto-char transform-start)
diff --git a/lisp/ol-w3m.el b/lisp/ol-w3m.el
index 517329889..80d6811a5 100644
--- a/lisp/ol-w3m.el
+++ b/lisp/ol-w3m.el
@@ -72,7 +72,7 @@ so that it can be yanked into an Org  buffer with links working correctly."
   (setq transform-start (region-beginning))
   (setq transform-end (region-end))
   ;; Deactivate mark if current mark is activate.
-  (when (fboundp 'deactivate-mark) (deactivate-mark)))
+  (deactivate-mark))
 (message "Transforming links...")
 (save-excursion
   (goto-char transform-start)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b94c79baa..fbbda3b47 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -661,7 +661,6 @@ there is no recent clock to choose from."
 		 (if (< i 10)
 			 (+ i ?0)
 		   (+ i (- ?A 10))) m))
-	(if (fboundp 'int-to-char) (setf (car s) (int-to-char (car s
 	(push s sel-list)))
 	(run-hooks 'org-clock-before-select-task-hook)
 	(goto-char (point-min))
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index c8443c135..ca64b11aa 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -513,8 +513,7 @@ for the duration of the command.")
 (defun org-columns-remove-overlays ()
   "Remove all currently active column overlays."
   (interactive)
-  (when (and (fboundp 'face-remap-remove-relative)
-	 org-columns-header-line-remap)
+  (when org-columns-header-line-remap
 (face-remap-remove-relative org-columns-header-line-remap)
 (setq org-columns-header-line-remap nil))
   (when org-columns-overlays
diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el
index 59a08d0b5..ccc2dfa22 100644
--- a/lisp/org-ctags.el
+++ b/lisp/org-ctags.el
@@ -509,10 +509,7 @@ Uses `ido-mode' if available.
 If the user enters a string that does not match an existing tag, create
 a new topic."
   (interactive)
-  (let* ((completing-read-fn (if (fboundp 'ido-completing-read)
- 'ido-completing-read
-   'completing-read))
- (tag (funcall completing-read-fn "Topic: " org-ctags-tag-list
+  (let* ((tag (ido-completing-read "Topic: " org-ctags-tag-list
nil 'confirm nil 'org-ctags-find-tag-history)))
 (when tag
   (cond
diff --git a/lisp/org-goto.el b/lisp/org-goto.el
index cd537..6162b7dde 100644
--- a/lisp/org-goto.el
+++ b/lisp/org-goto.el
@@ -110,10 +110,8 @@ When nil, you can use these keybindings to navigate the buffer:
 	  (org-defkey ma