[PATCH] Delete some Emacs 24 compat code

[PATCH] Delete some Emacs 24 compat code

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

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

[-- Attachment #2: 0001-Delete-some-Emacs-24-compat-code.patch --]
[-- Type: text/x-patch, Size: 11924 bytes --]

From 6e854576494f918c36cdd0ce698793574af494df Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
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))
-
 \f
 ;;; 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 (&optional _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!!"))))))
 
-
-\f
-;;; 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  &optional 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")
 
 \f
 ;;; 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-partition)
-      (seq-partition list n)
-    (unless (< n 1)
-      (let ((result '()))
-        (while list
-          (let (part)
-            (dotimes (_ n)
-              (when list (push (car list) part)))
-            (push part result))
-          (dotimes (_ n)
-            (setq list (cdr list))))
-        (nreverse result)))))
+;;; Handling killing/yanking of folded text
+
+(define-obsolete-function-alias 'org-fold-core--seq-partition #'seq-partition "9.6")
 
 ;; By default, all the text properties of the killed text are
 ;; preserved, including the folding text properties.  This can be
@@ -1386,7 +1370,7 @@ The arguments and return value are as specified for `filter-buffer-substring'."
                  ;; Yes, it is a hack.
                  ;; The below gives us string representation as a list.
                  ;; Note that we need to remove unreadable values, like markers (#<...>).
-                 (org-fold-core--seq-partition
+                 (seq-partition
                   (cdr (let ((data (read (replace-regexp-in-string
                                           "^#(" "("
                                           (replace-regexp-in-string
diff --git a/lisp/org-goto.el b/lisp/org-goto.el
index 6162b7dde..4eb361558 100644
--- a/lisp/org-goto.el
+++ b/lisp/org-goto.el
@@ -155,7 +155,7 @@ When nil, you can use these keybindings to navigate the buffer:
     (when (eq (lookup-key isearch-mode-map keys) 'isearch-printing-char)
       (isearch-mode t)
       (isearch-process-search-char (string-to-char keys))
-      (org-font-lock-ensure))))
+      (font-lock-ensure))))
 
 (defun org-goto-ret (&optional _arg)
   "Finish `org-goto' by going to the new location."
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index da68d8b8f..07c177b0b 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -70,18 +70,7 @@
 	     ,@body)
 	 (set-buffer-modified-p ,was-modified)))))
 
-;; FIXME: `partial-completion-mode' is obsolete since Emacs 24.1.
-(defmacro org-without-partial-completion (&rest body)
-  (declare (debug (body)))
-  `(if (and (boundp 'partial-completion-mode)
-	    partial-completion-mode
-	    (fboundp 'partial-completion-mode))
-       (unwind-protect
-	   (progn
-	     (partial-completion-mode -1)
-	     ,@body)
-	 (partial-completion-mode 1))
-     ,@body))
+(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6")
 
 (defmacro org-with-point-at (pom &rest body)
   "Move to buffer and point of point-or-marker POM for the duration of BODY."
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 58e5b252a..970663e6d 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -636,7 +636,7 @@ as `org-src-fontify-natively' is non-nil."
 	    ;; Add string and a final space to ensure property change.
 	    (insert string " "))
 	  (unless (eq major-mode lang-mode) (funcall lang-mode))
-	  (org-font-lock-ensure)
+          (font-lock-ensure)
 	  (let ((pos (point-min)) next)
 	    (while (setq next (next-property-change pos))
 	      ;; Handle additional properties from font-lock, so as to
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 54e2df20b..e84c2090f 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -4079,7 +4079,7 @@ COLUMNS is a sorted list of column numbers.  BEG and END are,
 respectively, the beginning position and the end position of the
 table."
   (org-with-wide-buffer
-   (org-font-lock-ensure beg end)
+   (font-lock-ensure beg end)
    (dolist (c columns)
      (goto-char beg)
      (let ((align nil)
@@ -4201,7 +4201,7 @@ beginning and end position of the current table."
      (org-table-expand begin end)
      ;; Make sure invisible characters in the table are at the right
      ;; place since column widths take them into account.
-     (org-font-lock-ensure begin end)
+     (font-lock-ensure begin end)
      (org-table--shrink-columns (sort columns #'<) begin end))))
 
 ;;;###autoload
@@ -4333,7 +4333,7 @@ FIELD is a string.  WIDTH is a number.  ALIGN is either \"c\",
     (org-table-save-field
      ;; Make sure invisible characters in the table are at the right
      ;; place since column widths take them into account.
-     (org-font-lock-ensure beg end)
+     (font-lock-ensure beg end)
      (move-marker org-table-aligned-begin-marker beg)
      (move-marker org-table-aligned-end-marker end)
      (goto-char beg)
diff --git a/lisp/org.el b/lisp/org.el
index 8b090ac0b..3bba06d18 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5751,7 +5751,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
     (insert s)
     (let ((org-odd-levels-only odd-levels))
       (org-mode)
-      (org-font-lock-ensure)
+      (font-lock-ensure)
       (if org-link-descriptive
           (org-link-display-format
            (buffer-string))
@@ -14129,7 +14129,7 @@ days in order to avoid rounding problems."
   "Convert a timestamp string S into a number of seconds."
   (float-time (org-time-string-to-time s)))
 
-(org-define-error 'org-diary-sexp-no-match "Unable to match diary sexp")
+(define-error 'org-diary-sexp-no-match "Unable to match diary sexp")
 
 (defun org-time-string-to-absolute (s &optional daynr prefer buffer pos)
   "Convert time stamp S to an absolute day number.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 66d1c5c60..1a239bb01 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2223,7 +2223,7 @@ is the language used for CODE, as a string, or nil."
 		    (funcall lang-mode)
 		    (insert code)
 		    ;; Fontify buffer.
-		    (org-font-lock-ensure)
+                    (font-lock-ensure)
 		    ;; Remove formatting on newline characters.
 		    (save-excursion
 		      (let ((beg (point-min))
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 5483c4504..7e4ae357e 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -3087,7 +3087,7 @@ and prefix with \"OrgSrc\".  For example,
 		 (with-temp-buffer
 		   (insert code)
 		   (funcall lang-mode)
-		   (org-font-lock-ensure)
+                   (font-lock-ensure)
 		   (buffer-string))))
 	 (fontifier (if use-htmlfontify-p 'org-odt-htmlfontify-string
 		      'org-odt--encode-plain-text))
diff --git a/lisp/ox-org.el b/lisp/ox-org.el
index 96d22d178..011d37616 100644
--- a/lisp/ox-org.el
+++ b/lisp/ox-org.el
@@ -328,7 +328,7 @@ Return output file name."
 	   (work-buffer (or visitingp (find-file-noselect filename)))
 	   newbuf)
       (with-current-buffer work-buffer
-        (org-font-lock-ensure)
+        (font-lock-ensure)
         (org-fold-show-all)
         (setq newbuf (htmlize-buffer)))
       (with-current-buffer newbuf
diff --git a/lisp/ox.el b/lisp/ox.el
index c75357b97..8420db7fc 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4151,7 +4151,7 @@ meant to be translated with `org-export-data' or alike."
 ;; `org-export-data' for further processing, depending on
 ;; `org-export-with-broken-links' value.
 
-(org-define-error 'org-link-broken "Unable to resolve link; aborting")
+(define-error 'org-link-broken "Unable to resolve link; aborting")
 
 (defun org-export-custom-protocol-maybe (link desc backend &optional info)
   "Try exporting LINK object with a dedicated function.
-- 
2.30.2

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Stefan Kangas <stefan@marxist.se> writes:

> 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

Thanks! I have some comments.

>  ;;; 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
> ...
> +(define-obsolete-function-alias 'org-fold-core--seq-partition #'seq-partition "9.6")

> diff --git a/lisp/org-macs.el b/lisp/org-macs.el
> index da68d8b8f..07c177b0b 100644
> --- a/lisp/org-macs.el
> +++ b/lisp/org-macs.el
> @@ -70,18 +70,7 @@
> ...
> +(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6")
                                                                   ^#'progn

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.

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

>>  ;;; 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
>> ...
>> +(define-obsolete-function-alias 'org-fold-core--seq-partition #'seq-partition "9.6")

Also, thinking a bit more. Do we need to obsolete the private function?
I think it is safe to remove it completely.

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Ihor Radchenko <yantar92@gmail.com> 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.

[-- Attachment #2: 0001-Delete-some-Emacs-24-compat-code.patch --]
[-- Type: text/x-patch, Size: 11959 bytes --]

From aa0637c22ff1465a19d4007f1e9d16cc0df9972c Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
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))
-
 \f
 ;;; 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 (&optional _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!!"))))))
 
-
-\f
-;;; 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  &optional 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")
 
 \f
 ;;; 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 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-partition)
-      (seq-partition list n)
-    (unless (< n 1)
-      (let ((result '()))
-        (while list
-          (let (part)
-            (dotimes (_ n)
-              (when list (push (car list) part)))
-            (push part result))
-          (dotimes (_ n)
-            (setq list (cdr list))))
-        (nreverse result)))))
+;;; Handling killing/yanking of folded text
 
 ;; By default, all the text properties of the killed text are
 ;; preserved, including the folding text properties.  This can be
@@ -1386,7 +1368,7 @@ The arguments and return value are as specified for `filter-buffer-substring'."
                  ;; Yes, it is a hack.
                  ;; The below gives us string representation as a list.
                  ;; Note that we need to remove unreadable values, like markers (#<...>).
-                 (org-fold-core--seq-partition
+                 (seq-partition
                   (cdr (let ((data (read (replace-regexp-in-string
                                           "^#(" "("
                                           (replace-regexp-in-string
diff --git a/lisp/org-goto.el b/lisp/org-goto.el
index 6162b7dde..4eb361558 100644
--- a/lisp/org-goto.el
+++ b/lisp/org-goto.el
@@ -155,7 +155,7 @@ When nil, you can use these keybindings to navigate the buffer:
     (when (eq (lookup-key isearch-mode-map keys) 'isearch-printing-char)
       (isearch-mode t)
       (isearch-process-search-char (string-to-char keys))
-      (org-font-lock-ensure))))
+      (font-lock-ensure))))
 
 (defun org-goto-ret (&optional _arg)
   "Finish `org-goto' by going to the new location."
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index da68d8b8f..e46e025d2 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -70,19 +70,6 @@
 	     ,@body)
 	 (set-buffer-modified-p ,was-modified)))))
 
-;; FIXME: `partial-completion-mode' is obsolete since Emacs 24.1.
-(defmacro org-without-partial-completion (&rest body)
-  (declare (debug (body)))
-  `(if (and (boundp 'partial-completion-mode)
-	    partial-completion-mode
-	    (fboundp 'partial-completion-mode))
-       (unwind-protect
-	   (progn
-	     (partial-completion-mode -1)
-	     ,@body)
-	 (partial-completion-mode 1))
-     ,@body))
-
 (defmacro org-with-point-at (pom &rest body)
   "Move to buffer and point of point-or-marker POM for the duration of BODY."
   (declare (debug (form body)) (indent 1))
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 58e5b252a..970663e6d 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -636,7 +636,7 @@ as `org-src-fontify-natively' is non-nil."
 	    ;; Add string and a final space to ensure property change.
 	    (insert string " "))
 	  (unless (eq major-mode lang-mode) (funcall lang-mode))
-	  (org-font-lock-ensure)
+          (font-lock-ensure)
 	  (let ((pos (point-min)) next)
 	    (while (setq next (next-property-change pos))
 	      ;; Handle additional properties from font-lock, so as to
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 54e2df20b..e84c2090f 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -4079,7 +4079,7 @@ COLUMNS is a sorted list of column numbers.  BEG and END are,
 respectively, the beginning position and the end position of the
 table."
   (org-with-wide-buffer
-   (org-font-lock-ensure beg end)
+   (font-lock-ensure beg end)
    (dolist (c columns)
      (goto-char beg)
      (let ((align nil)
@@ -4201,7 +4201,7 @@ beginning and end position of the current table."
      (org-table-expand begin end)
      ;; Make sure invisible characters in the table are at the right
      ;; place since column widths take them into account.
-     (org-font-lock-ensure begin end)
+     (font-lock-ensure begin end)
      (org-table--shrink-columns (sort columns #'<) begin end))))
 
 ;;;###autoload
@@ -4333,7 +4333,7 @@ FIELD is a string.  WIDTH is a number.  ALIGN is either \"c\",
     (org-table-save-field
      ;; Make sure invisible characters in the table are at the right
      ;; place since column widths take them into account.
-     (org-font-lock-ensure beg end)
+     (font-lock-ensure beg end)
      (move-marker org-table-aligned-begin-marker beg)
      (move-marker org-table-aligned-end-marker end)
      (goto-char beg)
diff --git a/lisp/org.el b/lisp/org.el
index 8b090ac0b..3bba06d18 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5751,7 +5751,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
     (insert s)
     (let ((org-odd-levels-only odd-levels))
       (org-mode)
-      (org-font-lock-ensure)
+      (font-lock-ensure)
       (if org-link-descriptive
           (org-link-display-format
            (buffer-string))
@@ -14129,7 +14129,7 @@ days in order to avoid rounding problems."
   "Convert a timestamp string S into a number of seconds."
   (float-time (org-time-string-to-time s)))
 
-(org-define-error 'org-diary-sexp-no-match "Unable to match diary sexp")
+(define-error 'org-diary-sexp-no-match "Unable to match diary sexp")
 
 (defun org-time-string-to-absolute (s &optional daynr prefer buffer pos)
   "Convert time stamp S to an absolute day number.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 66d1c5c60..1a239bb01 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2223,7 +2223,7 @@ is the language used for CODE, as a string, or nil."
 		    (funcall lang-mode)
 		    (insert code)
 		    ;; Fontify buffer.
-		    (org-font-lock-ensure)
+                    (font-lock-ensure)
 		    ;; Remove formatting on newline characters.
 		    (save-excursion
 		      (let ((beg (point-min))
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 5483c4504..7e4ae357e 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -3087,7 +3087,7 @@ and prefix with \"OrgSrc\".  For example,
 		 (with-temp-buffer
 		   (insert code)
 		   (funcall lang-mode)
-		   (org-font-lock-ensure)
+                   (font-lock-ensure)
 		   (buffer-string))))
 	 (fontifier (if use-htmlfontify-p 'org-odt-htmlfontify-string
 		      'org-odt--encode-plain-text))
diff --git a/lisp/ox-org.el b/lisp/ox-org.el
index 96d22d178..011d37616 100644
--- a/lisp/ox-org.el
+++ b/lisp/ox-org.el
@@ -328,7 +328,7 @@ Return output file name."
 	   (work-buffer (or visitingp (find-file-noselect filename)))
 	   newbuf)
       (with-current-buffer work-buffer
-        (org-font-lock-ensure)
+        (font-lock-ensure)
         (org-fold-show-all)
         (setq newbuf (htmlize-buffer)))
       (with-current-buffer newbuf
diff --git a/lisp/ox.el b/lisp/ox.el
index c75357b97..8420db7fc 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4151,7 +4151,7 @@ meant to be translated with `org-export-data' or alike."
 ;; `org-export-data' for further processing, depending on
 ;; `org-export-with-broken-links' value.
 
-(org-define-error 'org-link-broken "Unable to resolve link; aborting")
+(define-error 'org-link-broken "Unable to resolve link; aborting")
 
 (defun org-export-custom-protocol-maybe (link desc backend &optional info)
   "Try exporting LINK object with a dedicated function.
-- 
2.30.2

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Stefan Kangas <stefan@marxist.se> writes:

> Thanks, please find attached an updated patch.

Applied onto main via 0ed0dea22.

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Max Nikulin]

On 30/06/2022 18:19, Stefan Kangas wrote:
> 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

I have no particular opinion to which degree older Emacs versions should 
be supported, but I remember the following message:

Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100
https://list.orgmode.org/87fsrolmn9.fsf@gnu.org/

> Org is made of many areas and partial backward-compatibility can
> still be useful.  When people report compatibility problems with
> Emacs <26, we can guide them so that they enhance org-compat.el.
> 
> It is not because we don't promise compatibility for Emacs < 26
> that we should prevent backward-compatibility for Emacs < 26, and
> the all-or-nothing approach would actually prevent it.

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 30/06/2022 18:19, Stefan Kangas wrote:
>> 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
>
> I have no particular opinion to which degree older Emacs versions should 
> be supported, but I remember the following message:
>
> Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100
> https://list.orgmode.org/87fsrolmn9.fsf@gnu.org/

This is a valid point in general. However, Org mode already fails when
you try to load it using Emacs 24 (correct me if I am wrong). So, Org
cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do
not see much point keeping partial compatibility.

There is a reason to keep old compatibility code only when Org works in
general and only some new optional libraries cannot be used. This is not
the case for Emacs 24, AFAIK.

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales]

idk about others, but as a luddite follower of bugfix/maint, if
poissible and not too annoying to do, i would be interested in
knowing, at the email subject header level, that the upcoming
bugfix/maint release [state org version number] will not support <=
[state emacs version number] so that i can prepare at my glacial
luddite pace.  this is probably already done, but making it prominent
beforehand might help signal the need for changes with lots of time or
simplify git stuff [e.g. pull soon as the last pull and make a note
not to pull after that, which prevents the need for figuring out
rebasing again].


On 6/30/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 30/06/2022 18:19, Stefan Kangas wrote:
>>> 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
>>
>> I have no particular opinion to which degree older Emacs versions should
>> be supported, but I remember the following message:
>>
>> Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100
>> https://list.orgmode.org/87fsrolmn9.fsf@gnu.org/
>
> This is a valid point in general. However, Org mode already fails when
> you try to load it using Emacs 24 (correct me if I am wrong). So, Org
> cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do
> not see much point keeping partial compatibility.
>
> There is a reason to keep old compatibility code only when Org works in
> general and only some new optional libraries cannot be used. This is not
> the case for Emacs 24, AFAIK.
>
> Best,
> Ihor
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> idk about others, but as a luddite follower of bugfix/maint, if
> poissible and not too annoying to do, i would be interested in
> knowing, at the email subject header level, that the upcoming
> bugfix/maint release [state org version number] will not support <=
> [state emacs version number] so that i can prepare at my glacial
> luddite pace.  this is probably already done, but making it prominent
> beforehand might help signal the need for changes with lots of time or
> simplify git stuff [e.g. pull soon as the last pull and make a note
> not to pull after that, which prevents the need for figuring out
> rebasing again].

org.el contains the following:
;; Package-Requires: ((emacs "25.1"))

So, if you install Org from ELPA using built-in Emacs package manager,
Org will fail to install on older Emacs versions (AFAIU). I am not sure
if package.el if going to fall back to earlier Org version though.

In addition, we might also announce the oldest supported Emacs version
in https://orgmode.org/Changes.html. Either manually, or as a part of
some automated release script. Bastien, WDYT?

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales]

i use git version, not elpa, so for me, mailing list could tip me off
as early as possible, but not too early, if it said in email subject
header line that in a known upcoming release, it has been decided that
a specified emacs version will no longer be supported [note: i presume
and hope this would not occur in just a plain git update for such a
thing but would get a release that gets noted in email and get that
advance notice],

then upon seeig such email i can stop pulling from git until i am able
to upgrade emacs.  [lots of stuff takes lots and lots of time for me
in my case]  idk if practical, but just saying what seems like it
would be useful to me.

i would then stay at  something reasonably close to the first release
that does not support that version fo emacs.

On 6/30/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> idk about others, but as a luddite follower of bugfix/maint, if
>> poissible and not too annoying to do, i would be interested in
>> knowing, at the email subject header level, that the upcoming
>> bugfix/maint release [state org version number] will not support <=
>> [state emacs version number] so that i can prepare at my glacial
>> luddite pace.  this is probably already done, but making it prominent
>> beforehand might help signal the need for changes with lots of time or
>> simplify git stuff [e.g. pull soon as the last pull and make a note
>> not to pull after that, which prevents the need for figuring out
>> rebasing again].
>
> org.el contains the following:
> ;; Package-Requires: ((emacs "25.1"))
>
> So, if you install Org from ELPA using built-in Emacs package manager,
> Org will fail to install on older Emacs versions (AFAIU). I am not sure
> if package.el if going to fall back to earlier Org version though.
>
> In addition, we might also announce the oldest supported Emacs version
> in https://orgmode.org/Changes.html. Either manually, or as a part of
> some automated release script. Bastien, WDYT?
>
> Best,
> Ihor
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> i use git version, not elpa, so for me, mailing list could tip me off
> as early as possible, but not too early, if it said in email subject
> header line that in a known upcoming release, it has been decided that
> a specified emacs version will no longer be supported [note: i presume
> and hope this would not occur in just a plain git update for such a
> thing but would get a release that gets noted in email and get that
> advance notice],
>
> then upon seeig such email i can stop pulling from git until i am able
> to upgrade emacs.  [lots of stuff takes lots and lots of time for me
> in my case]  idk if practical, but just saying what seems like it
> would be useful to me.
>
> i would then stay at  something reasonably close to the first release
> that does not support that version fo emacs.
>
While what your asking for may sound reasonable, I don't think it is
practical. There is no sudden decision to stop supporting a version in
the sense that suddenly, at that point, the version is no longer
supported. We really only know that a past version is no longer
supported when it stops working and is more than 2 releases behind the
current Emacs version (any less and it is a bug which will get fixed).

The supported version policy has already been communicated on this
list. That policy will not change without notice, so you know exactly
what is supported at all times. 

There is no precise point where we can send out a message saying a
version is no longer supported. Best that can be done is say that any
Emacs version older than two releases behind the current stable release
is no longer supported. That doesn't mean it won't work, it just means
if there are problems, they won't be fixed and there should be no
expectation it will work if your running an unsupported Emacs version.

Thing is, no testing is done against older versions, so it isn't always
clear precisely when org stops working with an older unsupported
version.

Current stable version is 28. Therefore, if your running Emacs 25 or
earlier, you *should not* pull updates from git as they may not be
compatible with your Emacs version. When Emacs 29 is released, stop
pulling from git if your running Emacs <= version 26.

Of course, none of this is a big issue as you do build from git. Should
you find your most recent pull is no longer compatible with the version
of Emacs your running, it is trivial to revert to the version you were
running before - you just need to do a checkout for the earlier
revision and rebuild. As pointed out elsewhere in this thread,
package.el has minimum version spec, so this isn't an issue for
package.el users.

Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales]

your opinion is noted.  mine remains, but maintainers are welcome to
do as they think is right.  i stated what i thoguht might be useful
for my ase.  no further discussion needed.

On 6/30/22, Tim Cross <theophilusx@gmail.com> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> i use git version, not elpa, so for me, mailing list could tip me off
>> as early as possible, but not too early, if it said in email subject
>> header line that in a known upcoming release, it has been decided that
>> a specified emacs version will no longer be supported [note: i presume
>> and hope this would not occur in just a plain git update for such a
>> thing but would get a release that gets noted in email and get that
>> advance notice],
>>
>> then upon seeig such email i can stop pulling from git until i am able
>> to upgrade emacs.  [lots of stuff takes lots and lots of time for me
>> in my case]  idk if practical, but just saying what seems like it
>> would be useful to me.
>>
>> i would then stay at  something reasonably close to the first release
>> that does not support that version fo emacs.
>>
> While what your asking for may sound reasonable, I don't think it is
> practical. There is no sudden decision to stop supporting a version in
> the sense that suddenly, at that point, the version is no longer
> supported. We really only know that a past version is no longer
> supported when it stops working and is more than 2 releases behind the
> current Emacs version (any less and it is a bug which will get fixed).
>
> The supported version policy has already been communicated on this
> list. That policy will not change without notice, so you know exactly
> what is supported at all times.
>
> There is no precise point where we can send out a message saying a
> version is no longer supported. Best that can be done is say that any
> Emacs version older than two releases behind the current stable release
> is no longer supported. That doesn't mean it won't work, it just means
> if there are problems, they won't be fixed and there should be no
> expectation it will work if your running an unsupported Emacs version.
>
> Thing is, no testing is done against older versions, so it isn't always
> clear precisely when org stops working with an older unsupported
> version.
>
> Current stable version is 28. Therefore, if your running Emacs 25 or
> earlier, you *should not* pull updates from git as they may not be
> compatible with your Emacs version. When Emacs 29 is released, stop
> pulling from git if your running Emacs <= version 26.
>
> Of course, none of this is a big issue as you do build from git. Should
> you find your most recent pull is no longer compatible with the version
> of Emacs your running, it is trivial to revert to the version you were
> running before - you just need to do a checkout for the earlier
> revision and rebuild. As pointed out elsewhere in this thread,
> package.el has minimum version spec, so this isn't an issue for
> package.el users.
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Delete some Emacs 24 compat code

[Bastien Guerry]

Hi Ihor and Samuel,

Ihor Radchenko <yantar92@gmail.com> writes:

> In addition, we might also announce the oldest supported Emacs version
> in https://orgmode.org/Changes.html.

The current release of Org is meant to be compatible with the last
three major releases of Emacs.  That is, as of now, 28, 27, 26.

See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility

If the current release is de facto compatible with older Emacsen and
a new release will change this, yes, let's announce it in the release
notes.

We can also send an email to the list using the "X-Woof-Change" to
announce this upcoming change for the upcoming release.

For example, the current release of Org (9.5.4) is compatible with
Emacs 25.1, as Ihor noted.  This is older than Emacs 26.  If for some
reason Org 9.6 only supports Emacs >=26, let's announce it on the list
and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html.

I think doing this manually is fine.

Bug fixes from the maint branch should never change the compatibility
status of Org.

Evolutions on the master branch can change the compatibility, but not
break the global promise of being compatible with the last three major
releases of Emacs.

-- 
 Bastien

Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales]

great!  one of the things i like about org is the close attention to
user-oriented nature of maintenance.  everything on mailing list,
maint branch, compilation warnings few, etc.  this is more of the same
user-oriented goodness.

i have noticed an impressive amount of bug fixing, code improvement,
documentation improvement type of activity recently and it is greatly
appreciated.

it's a kind of user-openness attitude that i think improves the
software.  by analogy, kind of like including science-oriented
research subjects to get knowledge and noticing and priorities instead
of imposing an arbitrary wall.


On 7/17/22, Bastien Guerry <bzg@gnu.org> wrote:
> Hi Ihor and Samuel,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> In addition, we might also announce the oldest supported Emacs version
>> in https://orgmode.org/Changes.html.
>
> The current release of Org is meant to be compatible with the last
> three major releases of Emacs.  That is, as of now, 28, 27, 26.
>
> See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
>
> If the current release is de facto compatible with older Emacsen and
> a new release will change this, yes, let's announce it in the release
> notes.
>
> We can also send an email to the list using the "X-Woof-Change" to
> announce this upcoming change for the upcoming release.
>
> For example, the current release of Org (9.5.4) is compatible with
> Emacs 25.1, as Ihor noted.  This is older than Emacs 26.  If for some
> reason Org 9.6 only supports Emacs >=26, let's announce it on the list
> and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html.
>
> I think doing this manually is fine.
>
> Bug fixes from the maint branch should never change the compatibility
> status of Org.
>
> Evolutions on the master branch can change the compatibility, but not
> break the global promise of being compatible with the last three major
> releases of Emacs.
>
> --
>  Bastien
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> If the current release is de facto compatible with older Emacsen and
> a new release will change this, yes, let's announce it in the release
> notes.
>
> We can also send an email to the list using the "X-Woof-Change" to
> announce this upcoming change for the upcoming release.
>
> For example, the current release of Org (9.5.4) is compatible with
> Emacs 25.1, as Ihor noted.  This is older than Emacs 26.  If for some
> reason Org 9.6 only supports Emacs >=26, let's announce it on the list
> and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html.
>
> I think doing this manually is fine.
>
> Bug fixes from the maint branch should never change the compatibility
> status of Org.

Could you please elaborate on how exactly we can determine if a commit
changes the compatibility status? We can indeed catch some cases by
running tests on older Emacs versions, but it is by no means a reliable
measure.

Also, I just tried to run make EMACS=emacs-25 test, and it fails on bugfix.
Yet, Org can be usable on Emacs 25, but not fully.

Best,
Ihor

Re: [PATCH] Delete some Emacs 24 compat code

[Bastien]

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> Could you please elaborate on how exactly we can determine if a
> commit changes the compatibility status?

Today, we are interested in knowing whether Org is compatible with
Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.

Ideally, this means maintainers run the test suite against these
versions in order to check that bugfixes and/or new features don't
introduce incompatible code.

We don't need to run tests against Emacs <=25: if Org runs okay on
Emacs <=25, it's good.  If not, users can report it: maintainers are
not bound to fix such incompatibilities and we don't need to know or
to announce them beforehand since we don't make a promise that Org
will run with Emacs <=25.

On https://orgmode.org/worg/org-maintenance.html I added this:

  It does not mean that Org will not be usable, at least partially,
  with older Emacsen: but maintainers are not bound to fix bugs
  reported on them.

WDYT?

-- 
 Bastien

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Hi Bastien,

all you wrote is fine IMO. However, I think Ihor's point was mainly in
response to the request that we notify the list when compatibility is
going to be lost and that when it comes to versions less than the
currently maintained versions, this isn't really possible.

To put it in more concrete terms, based on your example below, we don't
know exactly when org loses compatibility with Emacs 25.x because we are
no longer testing against that version (we are only testing against 28,
27 and 26). We don't know the precise commit which breaks compatibility
with 25 as we are no longer testing against that version, so cannot
notify the list when compatibility is lost.

Obviously, when we do know, we can notify the list. Sometimes, it is
clear that a patch or commit will break compatibility with an old
version. However, we cannot provide any guarantee we will always notify
the list when that compatibility is lost. Often, this only becomes known
when someone posts to the list to say it no longer works. 

Therefore, I think the position should be that once an emacs version is
no longer one of the supported versions (current stable Emacs release
plus two previous major versions), there is no guarantee we will inform
the list when compatibility is lost. If you are running an unsupported
versions, either you should avoid updates or be prepared for breakage
without warning. When we do know a commit has broken compatibility, that
information will be relayed to the list, but we cannot guarantee we can
provide such information at the time the change is committed. Running an
unsupported versions is at your own risk.

Bastien <bzg@gnu.org> writes:

> Hi Ihor,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Could you please elaborate on how exactly we can determine if a
>> commit changes the compatibility status?
>
> Today, we are interested in knowing whether Org is compatible with
> Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.
>
> Ideally, this means maintainers run the test suite against these
> versions in order to check that bugfixes and/or new features don't
> introduce incompatible code.
>
> We don't need to run tests against Emacs <=25: if Org runs okay on
> Emacs <=25, it's good.  If not, users can report it: maintainers are
> not bound to fix such incompatibilities and we don't need to know or
> to announce them beforehand since we don't make a promise that Org
> will run with Emacs <=25.
>
> On https://orgmode.org/worg/org-maintenance.html I added this:
>
>   It does not mean that Org will not be usable, at least partially,
>   with older Emacsen: but maintainers are not bound to fix bugs
>   reported on them.
>
> WDYT?

Re: [PATCH] Delete some Emacs 24 compat code

[Bastien]

Hi Tim,

thanks for reminding me the context.

Tim Cross <theophilusx@gmail.com> writes:

> Therefore, I think the position should be that once an emacs version is
> no longer one of the supported versions (current stable Emacs release
> plus two previous major versions), there is no guarantee we will inform
> the list when compatibility is lost. 

Yes, fully agreed.  If my previous message was unclear: it is *good*
to inform the list of any compatibility issue (with any Emacsen), but
we cannot promise we will warn the list for every breakage as we don't
test Org with Emacs <=25.

> If you are running an unsupported
> versions, either you should avoid updates or be prepared for breakage
> without warning. When we do know a commit has broken compatibility, that
> information will be relayed to the list, but we cannot guarantee we can
> provide such information at the time the change is committed. Running an
> unsupported versions is at your own risk.

Yes, thanks for articulating this very clearly.

-- 
 Bastien

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Therefore, I think the position should be that once an emacs version is
>> no longer one of the supported versions (current stable Emacs release
>> plus two previous major versions), there is no guarantee we will inform
>> the list when compatibility is lost. 
>
> Yes, fully agreed.  If my previous message was unclear: it is *good*
> to inform the list of any compatibility issue (with any Emacsen), but
> we cannot promise we will warn the list for every breakage as we don't
> test Org with Emacs <=25.

Should we document this workflow in
https://orgmode.org/worg/org-maintenance.html ?

>> If you are running an unsupported
>> versions, either you should avoid updates or be prepared for breakage
>> without warning. When we do know a commit has broken compatibility, that
>> information will be relayed to the list, but we cannot guarantee we can
>> provide such information at the time the change is committed. Running an
>> unsupported versions is at your own risk.
>
> Yes, thanks for articulating this very clearly.

Maybe we can add this information to the manual in the Installation section?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] Delete some Emacs 24 compat code

[Bastien]

Ihor Radchenko <yantar92@gmail.com> writes:

> Should we document this workflow in
> https://orgmode.org/worg/org-maintenance.html ?

I slightly updated the page again, let me know if it's clear:
https://orgmode.org/worg/org-maintenance.html

>>> If you are running an unsupported
>>> versions, either you should avoid updates or be prepared for breakage
>>> without warning. When we do know a commit has broken compatibility, that
>>> information will be relayed to the list, but we cannot guarantee we can
>>> provide such information at the time the change is committed. Running an
>>> unsupported versions is at your own risk.
>>
>> Yes, thanks for articulating this very clearly.
>
> Maybe we can add this information to the manual in the Installation
> section?

Yes, maybe just one sentence regarding Emacs compatibility like 

  "Org releases are compatible with the latest three major Emacs
  releases."

with a footnote pointing to
https://orgmode.org/worg/org-maintenance.html

Thanks,

-- 
 Bastien

Re: [PATCH] Delete some Emacs 24 compat code

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Should we document this workflow in
>> https://orgmode.org/worg/org-maintenance.html ?
>
> I slightly updated the page again, let me know if it's clear:
> https://orgmode.org/worg/org-maintenance.html

Thanks! LGTM!

>> Maybe we can add this information to the manual in the Installation
>> section?
>
> Yes, maybe just one sentence regarding Emacs compatibility like 
>
>   "Org releases are compatible with the latest three major Emacs
>   releases."
>
> with a footnote pointing to
> https://orgmode.org/worg/org-maintenance.html

Sounds reasonable, though we might emphasize a bit more that it is
relevant to the latest Org from ELPA/git.

We have

       If, for one reason or another, you want to install Org on top of this
    pre-packaged version, you can use the Emacs package system or clone
    Org’s git repository.

Adding the information that Org from ELPA/git is only compatible with
certain Emacs versions is important.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] Delete some Emacs 24 compat code

[Bastien]

Ihor Radchenko <yantar92@gmail.com> writes:

> Sounds reasonable, though we might emphasize a bit more that it is
> relevant to the latest Org from ELPA/git.
>
> We have
>
>        If, for one reason or another, you want to install Org on top of this
>     pre-packaged version, you can use the Emacs package system or clone
>     Org’s git repository.
>
> Adding the information that Org from ELPA/git is only compatible with
> certain Emacs versions is important.

I tried something in https://git.sr.ht/~bzg/org-mode/commit/b428839f
but feel free to enhance the wording if needed.

-- 
 Bastien

Re: [PATCH] Delete some Emacs 24 compat code

[Max Nikulin]

On 08/08/2022 22:46, Bastien wrote:
> Ihor Radchenko writes:
> 
>> Could you please elaborate on how exactly we can determine if a
>> commit changes the compatibility status?
> 
> Today, we are interested in knowing whether Org is compatible with
> Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.

Please, keep ";; Package-Requires: " version in org.el consistent with 
such statement (Should it be updated for the bugfix branch as well?).

Such commit may be accompanied by an announce sent to the mail list. 
Samuel may check this declaration in his update script.

The problem is that it is too easy to forget to make such change before 
committing of something that really breaks compatibility.

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 08/08/2022 22:46, Bastien wrote:
>> Ihor Radchenko writes:
>> 
>>> Could you please elaborate on how exactly we can determine if a
>>> commit changes the compatibility status?
>> Today, we are interested in knowing whether Org is compatible with
>> Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.
>
> Please, keep ";; Package-Requires: " version in org.el consistent with such statement
> (Should it be updated for the bugfix branch as well?).
>
> Such commit may be accompanied by an announce sent to the mail list. Samuel may check this
> declaration in his update script.
>

The above is good to do and your right, it is hard not to forget to do
this. However, this is somewhat independent of whether there has been a
commit which breaks compatibility with a version. This is something
which should be updated when a new major version of Emacs is
released. It really just states which version org is (should be)
compatible with. It says little about which versions it actually is
compatible with i.e. it might say Emacs versions 28.x, 27.x and 26.x,
but that doesn't mean it isn't compatible with 25.x - it only says that
if it doesn't work with 25.x, that is not considered a bug. . 

> The problem is that it is too easy to forget to make such change before committing of
> something that really breaks compatibility.

That is a problem, but the real problem is that you don't know you have
broken compatibility because your likely no longer testing against that
version. Sometimes you will and we should inform the community when we
know, but we cannot guarantee we will always let the list know
immediately when compatibility is lost for these no longer supported
versions.

Re: [PATCH] Delete some Emacs 24 compat code

[Tom Gillespie]

> Please, keep ";; Package-Requires: " version in org.el consistent with
> such statement (Should it be updated for the bugfix branch as well?).

Unfortunately it is not clear that this is the right thing to do because
nearly every feature of org may work on old versions. Should we put
users through the pain of having to fight the metadata saying that they
can't run org on an old version of emacs when only a tiny subfeature
may or may not be broken? For example, I can load the current
version of org and go through most of my normal workflows without
issue on 25.

Package-Requires does not mean what it says, what it actually means
is "actively does not work on any versions not specified" which is not
true if we were to say >=26 and would make users' of older versions
of emacs lives harder. What this means is that we could say >=25
(which is what org.el current has by listing 25.1) because it is possible
to load current versions of org-mode on 25 but not on 24 (which works
only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da).

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Tom Gillespie <tgbugs@gmail.com> writes:

>> Please, keep ";; Package-Requires: " version in org.el consistent with
>> such statement (Should it be updated for the bugfix branch as well?).
>
> Unfortunately it is not clear that this is the right thing to do because
> nearly every feature of org may work on old versions. Should we put
> users through the pain of having to fight the metadata saying that they
> can't run org on an old version of emacs when only a tiny subfeature
> may or may not be broken? For example, I can load the current
> version of org and go through most of my normal workflows without
> issue on 25.
>
> Package-Requires does not mean what it says, what it actually means
> is "actively does not work on any versions not specified" which is not
> true if we were to say >=26 and would make users' of older versions
> of emacs lives harder. What this means is that we could say >=25
> (which is what org.el current has by listing 25.1) because it is possible
> to load current versions of org-mode on 25 but not on 24 (which works
> only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da).

The manual actually says

  "If this exists, it names packages on which the current package
  depends for proper operation."

so I think it is reasonable to only list the minimum supported Emacs
version, not the minimum version where it partially or fully works, but
is not supported.

Problem I see with your approach is there will be an expectation that if
it lists Emacs 25.x that it works under that version and anything which
doesn't work is a bug. People will not check this list, README or NEWS
files to verify what version of Emacs is compatible with - if they can
use package.el to install it, they will expect that it works without any
issues and any encountered are either a configuration error or a bug.

Even worse, once a problem with (for example) Emacs 25.x is found, what
do we do? Would we have to push out a new version just to now update the
requires line and forcing an update for all users? Which commit do we
use to push out that update (given there will have been changes since
the last release and we may not be ready to push them out in a new
version yet). 

An alternative approach is to deliberately make it harder to upgrade org
if your running an unsupported version of Emacs. This would prevent
automatic updates to a version which is not supported and (possibly) doe
sot work, either partially or fully.  Manage user expectations by making
it very explicit to the end user they are running a older version of
emacs which may not be compatible with latest version of org.They can
either decide to continue with the existing version they have installed
or they can upgrade to a more recent Emacs or they can install org
manually if they really want to accept the risk and run in an
unsupported configuration.

Re: [PATCH] Delete some Emacs 24 compat code

[Tom Gillespie]

> The manual actually says
>
>   "If this exists, it names packages on which the current package
>   depends for proper operation."
>
> so I think it is reasonable to only list the minimum supported Emacs
> version, not the minimum version where it partially or fully works, but
> is not supported.

The weasel words here are "proper operation" because it covers everything
from "will byte compile without errors (but maybe with warnings)" to "has
zero bugs and will never fail under any circumstances." My interpretation
is that Package-Requires means "will byte compile without errors" because
all software has bugs. Unfortunately package metadata doesn't seem to
have another field for something like Package-Supported-Version.

> Problem I see with your approach is there will be an expectation that if
> it lists Emacs 25.x that it works under that version and anything which
> doesn't work is a bug. People will not check this list, README or NEWS
> files to verify what version of Emacs is compatible with - if they can
> use package.el to install it, they will expect that it works without any
> issues and any encountered are either a configuration error or a bug.

I agree that this is an issue. I think the easiest solution would be to add
something to org-submit-bug-report which would inform the user that they
are running a version of org that is too new for their version of emacs and
is thus unsupported.

Another solution would be for package metadata to deconflate "will
immediately fail if you try to run this on old versions" from "only make
this update available to users running emacs at or above this version."
I think this is a variant of your suggestion to make upgrading to unsupported
versions more difficult but not impossible.

> Even worse, once a problem with (for example) Emacs 25.x is found, what
> do we do? Would we have to push out a new version just to now update the
> requires line and forcing an update for all users? Which commit do we
> use to push out that update (given there will have been changes since
> the last release and we may not be ready to push them out in a new
> version yet).

I don't see how a bug that is only encountered on 25 is different from
any other bug in this case. We aren't going to continue to support
25 by continuing to maintain a 9.5.x branch when we go on to 9.6,
but as long as we don't e.g. start using e.g. functions that are not
present in 25 that cause immediate runtime failures or byte compile
failures, then hard blocking users on 25 from installing from elpa at
all seems like artificially depriving users of the ability to choose at
their own risk (albeit to make the maintainer's lives easier).

> An alternative approach is to deliberately make it harder to upgrade org
> if your running an unsupported version of Emacs. This would prevent
> automatic updates to a version which is not supported and (possibly) doe
> sot work, either partially or fully.  Manage user expectations by making
> it very explicit to the end user they are running a older version of
> emacs which may not be compatible with latest version of org.They can
> either decide to continue with the existing version they have installed
> or they can upgrade to a more recent Emacs or they can install org
> manually if they really want to accept the risk and run in an
> unsupported configuration.

As mentioned above, I also like this approach. We could create a hack
to work around the missing package metadata field, which would cause
a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
or some such is non-nil. The error message would say something along
the lines of "this version of org {org-version} will run on {emacs-version}"
but it is not supported. If you still want to install it, please run
(setq org-i-know-what-i-am-doing t) and then install the package again"
or something like that.

Best!

Tom

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Tom Gillespie <tgbugs@gmail.com> writes:

>
> As mentioned above, I also like this approach. We could create a hack
> to work around the missing package metadata field, which would cause
> a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
> or some such is non-nil. The error message would say something along
> the lines of "this version of org {org-version} will run on {emacs-version}"
> but it is not supported. If you still want to install it, please run
> (setq org-i-know-what-i-am-doing t) and then install the package again"
> or something like that.
>

What I don't like with this approach is that I think it is making
everything far too complicated. The other issue at the core of this is
that we don't always know if it actually does run on an unsupported
version as no testing is done against those earlier versions. We would
have to have a message like "It may or may not work on this unsupported
version of emacs, run at your own risk."

Personally, I would just keep it far simpler. Anyone running a version
of Emacs which is 4 major versions behind the current stable release
should expect problems and challewnges if they also want to run the
latest versions of packages under a version that old . When that out of
datge, I think it is reasonable to expect that if you want to install
the latest version, you will need to do it manually and not via
package.el. 

I don't think we have the resources for anything more complicated. We
state what versions it is supported on and leave it at that. When we say
supported, we can extgend that to mean able to be installed via
package.el.

Recall where all this started. Samuel wanted to be able to run Org on a
unsupported version of Emacs and for there to be a message or some sort
of alert once org no longer runs under that version of
Emacs. Unfortunately, with a package a large and complex as org,
defining what no longer runs means is difficult because that will
largely depend on which features you rely on. The other problem is we
don't test against unsupported versions, so we only know when a
feature/facility no longer works once someone reports it. Even then, it
may not be straight-forward as the feature/function may only be broken
in some configuration scenarios.

I do like the idea of having the bug reporting functionality check
whether the version being used is a supported version and alerting the
user when it isn't. Otherwise, I think keep it very simple. Make it
clear what is supported and only enable it to be installedl via
package.el on versions of Emacs which are in the supported version
list. Anyone outside that list can either stick with the version they
have installed (no updates), manually install and run the risk or plan
to update Emacs to a supported version.

At the end of the day, we are not forcing anyone to upgrade. They can
continue to use the version they have running under Emacs 25 for as long
as they want. Obviously, it won't get bug fixes etc, but that is what
unsupported means. I suspect most people would rather have package.el
tell them that their Emacs version is not supported than have it
silently do the update and then find some feature they rely on no longer
works (especially as downgrading a package to an earlier versions isn't
something package.el supports). . 

Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales]

tim cross, i would like to ask politely for you personally to
henceforth please be VERY VERY careful when you say that i said or
wanted something or tried to do something.  i am not referring to this
thread but general espeially in another thread.

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> tim cross, i would like to ask politely for you personally to
> henceforth please be VERY VERY careful when you say that i said or
> wanted something or tried to do something.  i am not referring to this
> thread but general espeially in another thread.

apologies if I've caused some form of offence - definitely not my
intention. However, I'm not sure what other thread your referring to. As
far as I can recall, this is the only thread I've mention you by name.

Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

Samuel Wales <samologist@gmail.com> writes:

> tim cross, i would like to ask politely for you personally to
> henceforth please be VERY VERY careful when you say that i said or
> wanted something or tried to do something.  i am not referring to this
> thread but general espeially in another thread.


BTW, just for the record, what I was referring to were the two posts
where you wrote

> idk about others, but as a luddite follower of bugfix/maint, if
> poissible and not too annoying to do, i would be interested in
> knowing, at the email subject header level, that the upcoming
> bugfix/maint release [state org version number] will not support <=
> [state emacs version number] so that i can prepare at my glacial
> luddite pace.  this is probably already done, but making it prominent
> beforehand might help signal the need for changes with lots of time or
> simplify git stuff [e.g. pull soon as the last pull and make a note
> not to pull after that, which prevents the need for figuring out
> rebasing again].

and in particular

> i use git version, not elpa, so for me, mailing list could tip me off
> as early as possible, but not too early, if it said in email subject
> header line that in a known upcoming release, it has been decided that
> a specified emacs version will no longer be supported [note: i presume
> and hope this would not occur in just a plain git update for such a
> thing but would get a release that gets noted in email and get that
> advance notice],

> then upon seeig such email i can stop pulling from git until i am able
> to upgrade emacs.  [lots of stuff takes lots and lots of time for me
> in my case]  idk if practical, but just saying what seems like it
> would be useful to me.

> i would then stay at  something reasonably close to the first release
> that does not support that version fo emacs.

and the only point I wanted to make is that this isn't practical because
we don't always know when a patch removes compatibility for a
non-supported version of Emacs (i.e. major version four or more versions
behind current major version).

The other point to note is that git commits are not releases and
commits happen before releases. So, while an org release does specify
precisely which Emacs versions are supported, commits occur in-between
releases. Supported versions don't change during those commits, but
support for older unsupported versions of emacs could be lost at any
commit and as we don't test against those older versions, we won't know
until someone reports it later. 

At the end of the day, if your running org in an Emacs version which is
four or more major versions behind the current stable release, you are
at risk of breakage at any update and this is likely to happen without
notice (if you update often, you are likely to be the first person to
discover the loss of compatibility).

Good news is, as your running from git, it is trivial to revert back to
an earlier version. Something which ELPA users cannot do.