Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/26/2024 5:56 AM, Ihor Radchenko wrote: Thanks! Applied, onto main. I moved the NEWS entry to Miscellaneous. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=66cb45658 Thanks for merging!
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/25/2024 7:09 AM, Ihor Radchenko wrote:
Ok. Now, may you also add NEWS entry?
See attached. I made my best guess on what subsection of NEWS to use
("New functions and changes in function arguments"), but maybe that's
not quite right. It didn't seem to fit in any of the other sections very
well either, though...From 17b2bae16a5e07f09599b521563536037daa0f8c Mon Sep 17 00:00:00 2001
From: Jim Porter
Date: Mon, 6 Nov 2023 11:39:09 -0800
Subject: [PATCH] Add support for 'thing-at-point' to get URL at point
* lisp/org.el (thingatpt): Require.
(org--link-at-point, org--bounds-of-link-at-point): New functions...
(org-mode): ... add to 'thing-at-point-provider-alist' and friends.
* testing/lisp/test-org.el (test-org/thing-at-point/url): New test.
* etc/ORG-NEWS: Announce this change.
---
etc/ORG-NEWS | 5 +
lisp/org.el | 25 +
testing/lisp/test-org.el | 13 +
3 files changed, 43 insertions(+)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index e2bbe3e0e..d5d891ba0 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1474,6 +1474,11 @@ optional argument =NEW-HEADING-CONTAINER= specifies
where in the
buffer it will be added. If not specified, new headings are created
at level 1 at the end of the accessible part of the buffer, as before.
+*** Org links now support ~thing-at-point~
+
+You can now retrieve the destination of a link by calling
+~(thing-at-point 'url)~.
+
** Miscellaneous
*** Add completion for links to man pages
diff --git a/lisp/org.el b/lisp/org.el
index ed18565bd..656f628ba 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -81,6 +81,7 @@
(require 'calendar)
(require 'find-func)
(require 'format-spec)
+(require 'thingatpt)
(condition-case nil
(load (concat (file-name-directory load-file-name)
@@ -5041,6 +5042,19 @@ The following commands are available:
#'pcomplete-completions-at-point nil t)
(setq-local buffer-face-mode-face 'org-default)
+ ;; `thing-at-point' support
+ (setq-local thing-at-point-provider-alist
+ (cons '(url . org--link-at-point)
+thing-at-point-provider-alist))
+ (when (boundp 'forward-thing-provider-alist)
+(setq-local forward-thing-provider-alist
+(cons '(url . org-next-link)
+ forward-thing-provider-alist)))
+ (when (boundp 'bounds-of-thing-at-point-provider-alist)
+(setq-local bounds-of-thing-at-point-provider-alist
+(cons '(url . org--bounds-of-link-at-point)
+ bounds-of-thing-at-point-provider-alist)))
+
;; If empty file that did not turn on Org mode automatically, make
;; it to.
(when (and org-insert-mode-line-in-empty-file
@@ -8753,6 +8767,17 @@ there is one, return it."
(setq link (nth (1- nth) links)
(cons link end)
+(defun org--link-at-point ()
+ "`thing-at-point' provider function."
+ (org-element-property :raw-link (org-element-context)))
+
+(defun org--bounds-of-link-at-point ()
+ "`bounds-of-thing-at-point' provider function."
+ (let ((context (org-element-context)))
+(when (eq (org-element-type context) 'link)
+ (cons (org-element-begin context)
+(org-element-end context)
+
;;; File search
(defun org-do-occur (regexp cleanup)
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 072d405bd..519b96647 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -3630,6 +3630,19 @@ Foo Bar
(org-open-at-point))
nil)
+
+;;; Thing at point
+
+(ert-deftest test-org/thing-at-point/url ()
+ "Test that `thing-at-point' returns the URL at point."
+ (org-test-with-temp-text
+ "[[https://www.gnu.org/software/emacs/][GNU Emacs]]"
+(should (string= (thing-at-point 'url)
+ "https://www.gnu.org/software/emacs/;))
+(when (boundp 'bounds-of-thing-at-point-provider-alist)
+ (should (equal (bounds-of-thing-at-point 'url)
+ '(1 . 51))
+
;;; Node Properties
--
2.25.1
Re: Adding custom providers for thingatpt.el
On 5/21/2024 3:32 AM, Max Nikulin wrote: On 20/05/2024 09:33, Jim Porter wrote: +++ b/lisp/org.el @@ -81,6 +81,7 @@ (require 'calendar) (require 'find-func) (require 'format-spec) +(require 'thingatpt) So it becomes hard dependency. However it seems thingatpt is anyway loaded through some indirect dependency. Probably through ol-eww.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/20/2024 3:41 AM, Ihor Radchenko wrote: Jim Porter writes: + (when (boundp 'forward-thing-provider-alist) +(setq-local forward-thing-provider-alist +(cons '(url . org-next-link) + forward-thing-provider-alist))) According to the docstring, functions in `forward-thing-provider-alist' should accept a single argument - the number of "things" to skip forward/backward. But it is not what `org-next-link' expects. In a twist, it turns out *this* patch for Org-mode was correct, and my prior patch for thingatpt.el was wrong. In short, 'forward-thing' now calls the functions in 'forward-thing-provider-alist' with a BACKWARD flag, rather than an integer N. That's because 'forward-thing' needs to account for the case where you have multiple providers for the same "thing", and so it needs to go one at a time checking all the providers for the best match (read: the one that moves point by the smallest non-zero amount). I've now pushed the thingatpt fix to the Emacs master branch.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/19/2024 6:34 PM, Jim Porter wrote: On 5/18/2024 1:26 AM, Eli Zaretskii wrote: I think you can install this now. Thanks. Merged as ae9045a8bd8. Ihor, I'll update the Org-mode part of this next and post the new patch for that to the Org list once it's ready. ... and here's the Org-mode patch for this.From 93c485f5348c879ef2328e00035d7b16a7d94342 Mon Sep 17 00:00:00 2001 From: Jim Porter Date: Mon, 6 Nov 2023 11:39:09 -0800 Subject: [PATCH] Add support for 'thing-at-point' to get URL at point * lisp/org.el (thingatpt): Require. (org--link-at-point, org--bounds-of-link-at-point): New functions... (org-mode): ... add to 'thing-at-point-provider-alist' and friends. * testing/lisp/test-org.el (test-org/thing-at-point/url): New test. --- lisp/org.el | 25 + testing/lisp/test-org.el | 13 + 2 files changed, 38 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 5e9f479fb..0c2f347ff 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -81,6 +81,7 @@ (require 'calendar) (require 'find-func) (require 'format-spec) +(require 'thingatpt) (condition-case nil (load (concat (file-name-directory load-file-name) @@ -5042,6 +5043,19 @@ The following commands are available: #'pcomplete-completions-at-point nil t) (setq-local buffer-face-mode-face 'org-default) + ;; `thing-at-point' support + (setq-local thing-at-point-provider-alist + (cons '(url . org--link-at-point) +thing-at-point-provider-alist)) + (when (boundp 'forward-thing-provider-alist) +(setq-local forward-thing-provider-alist +(cons '(url . org-next-link) + forward-thing-provider-alist))) + (when (boundp 'bounds-of-thing-at-point-provider-alist) +(setq-local bounds-of-thing-at-point-provider-alist +(cons '(url . org--bounds-of-link-at-point) + bounds-of-thing-at-point-provider-alist))) + ;; If empty file that did not turn on Org mode automatically, make ;; it to. (when (and org-insert-mode-line-in-empty-file @@ -8752,6 +8766,17 @@ there is one, return it." (setq link (nth (1- nth) links) (cons link end) +(defun org--link-at-point () + "`thing-at-point' provider function." + (org-element-property :raw-link (org-element-context))) + +(defun org--bounds-of-link-at-point () + "`bounds-of-thing-at-point' provider function." + (let ((context (org-element-context))) +(when (eq (org-element-type context) 'link) + (cons (org-element-begin context) +(org-element-end context) + ;;; File search (defun org-do-occur (regexp cleanup) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 23d12b26a..a83078e45 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -3630,6 +3630,19 @@ Foo Bar (org-open-at-point)) nil) + +;;; Thing at point + +(ert-deftest test-org/thing-at-point/url () + "Test that `thing-at-point' returns the URL at point." + (org-test-with-temp-text + "[[https://www.gnu.org/software/emacs/][GNU Emacs]]" +(should (string= (thing-at-point 'url) + "https://www.gnu.org/software/emacs/;)) +(when (boundp 'bounds-of-thing-at-point-provider-alist) + (should (equal (bounds-of-thing-at-point 'url) + '(1 . 51)) + ;;; Node Properties -- 2.25.1
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/18/2024 1:26 AM, Eli Zaretskii wrote: I think you can install this now. Thanks. Merged as ae9045a8bd8. Ihor, I'll update the Org-mode part of this next and post the new patch for that to the Org list once it's ready.
Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/7/2024 5:20 AM, Eli Zaretskii wrote: I disagree. These functions are nowadays the basis of many interactive features, and users are usually mightily confused by the fine print of what "at point" means technically in Emacs. The current operation is much easier for users to grasp mentally by observing the position of the cursor, whether it's on or just after the "thing". At the risk of veering off-topic (I mainly care about adding 'bounds-of-thing-at-point-provider-alist' and 'forward-thing-provider-alist'), would adding a new optional STRICT argument to 'thing-at-point' and friends be an ok resolution for everyone? This argument would enable Drew's proposed behavior. That way, users get all the nice behavior by default just like today, and programmers who require strict correctness in their code also have an option.
Re: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 4/30/2024 2:10 PM, Drew Adams wrote: I've also fixed a bug in EWW and bug-reference-mode where it would return nil for (thing-at-point 'url) if point was at the *end* of a URL. By "at the end" I assume you really mean just _after_ a URL, i.e., no longer on/at the URL. FWIW, that's actually _superior_ behavior. Unfortunately however, Emacs has chosen the behavior you describe here: It's now consistent with how 'thing-at-point' works by default. (If you have two consecutive URLs and point is between them...it'll prefer the second one.) Which is better! It's what "at point" means. [snip] See bug #9300, " `bounds-of-thing-at-point' does not return nil when just after THING". I agree overall that your proposed behavior is more correct, and it's probably how I'd have implemented 'thing-at-point' if I were doing it from scratch. However, I think an even worse outcome than "thing-at-point looks at point or before-point" is "sometimes thing-at-point just looks at point, and other times it looks at point or before-point" (which is what it does today). I'd even be open to something like a 'thing-at-point-is-strict' defvar that people could let-bind as wanted, but I'm not going to *argue* for that myself. Ultimately though, this patch is really just about providing the necessary defcustoms for org-mode to be able to use 'thing-at-point' (and for Ihor to feel ok about it ;)). Changing 'thing-at-point's behavior should probably be handled separately, especially since there'd be an uphill battle to revisit the decision in bug#9300.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 4/30/2024 4:39 AM, Ihor Radchenko wrote: What happens if you have multiple providers for an URL? You add the provider to the end, so it will have the lower priority in this scenario. I guess that you want the opposite - EWW provider to take precedence. Same for other changes. That's probably reasonable. I was just keeping things the way they were historically here, but we might as well fix this now. It would make sense to add tests for "first wins" behaviour. Done. I've also fixed a bug in EWW and bug-reference-mode where it would return nil for (thing-at-point 'url) if point was at the *end* of a URL. It's now consistent with how 'thing-at-point' works by default. (If you have two consecutive URLs and point is between them - only possible with the custom provider function, I think - it'll prefer the second one.) From da26f0160c955f15e123e5b28cf8a9f514395e21 Mon Sep 17 00:00:00 2001 From: Jim Porter Date: Sun, 28 Apr 2024 21:19:53 -0700 Subject: [PATCH] Allow defining custom providers for more "thingatpt" functions This also fixes an issue in EWW and bug-reference-mode where (thing-at-point 'url) at the end of a URL would return nil. * lisp/thingatpt.el (forward-thing-provider-alist) (bounds-of-thing-at-point-provider-alist): New variables... (forward-thing, bounds-of-thing-at-point): ... use them. (text-property-search-forward, text-property-search-backward) (prop-match-beginning, prop-match-end): Declare. (thing-at-point-for-text-property, forward-thing-for-text-property) (bounds-of-thing-at-point-for-text-property): New functions. * lisp/net/eww.el (eww--url-at-point): Use 'thing-at-point-for-text-property'. (eww--bounds-of-url-at-point, eww--forward-url): New functions... (eww-mode): ... use them. * lisp/progmodes/bug-reference.el (bug-reference--url-at-point): Use 'thing-at-point-for-text-property'. (bug-reference--bounds-of-url-at-point, bug-reference--forward-url): New functions... (bug-reference--init): ... use them. * test/lisp/thingatpt-tests.el (thing-at-point-providers) (forward-thing-providers, bounds-of-thing-at-point-providers): New tests. * etc/NEWS: Announce this change. --- etc/NEWS| 25 -- lisp/net/eww.el | 21 +++-- lisp/progmodes/bug-reference.el | 26 +-- lisp/thingatpt.el | 83 +++-- test/lisp/thingatpt-tests.el| 59 +++ 5 files changed, 198 insertions(+), 16 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 7efb4110bcd..061161bb2fd 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1591,19 +1591,34 @@ of the currently existing keyboards macros using the new mode duplicating them, deleting them, and editing their counters, formats, and keys. -** Miscellaneous +** Thingatpt --- -*** Webjump now assumes URIs are HTTPS instead of HTTP. -For links in 'webjump-sites' without an explicit URI scheme, it was -previously assumed that they should be prefixed with "http://;. Such -URIs are now prefixed with "https://; instead. +*** New variables for providing custom thingatpt implementations. +The new variables 'bounds-of-thing-at-point-provider-alist' and +'forward-thing-provider-alist' now allow defining custom implementations +of 'bounds-of-thing-at-point' and 'forward-thing', respectively. + +--- +*** New helper functions for text property-based thingatpt providers. +The new helper functions 'thing-at-point-for-text-property', +'bounds-of-thing-at-point-for-text-property', and +'forward-thing-for-text-property' can help to help implement custom +thingatpt providers for "things" that are defined by a text property. --- *** 'bug-reference-mode' now supports 'thing-at-point'. Now, calling '(thing-at-point 'url)' when point is on a bug reference will return the URL for that bug. +** Miscellaneous + +--- +*** Webjump now assumes URIs are HTTPS instead of HTTP. +For links in 'webjump-sites' without an explicit URI scheme, it was +previously assumed that they should be prefixed with "http://;. Such +URIs are now prefixed with "https://; instead. + +++ *** New user option 'rcirc-log-time-format' This allows for rcirc logs to use a custom timestamp format, than the diff --git a/lisp/net/eww.el b/lisp/net/eww.el index 39ea964d47a..b3997786d9e 100644 --- a/lisp/net/eww.el +++ b/lisp/net/eww.el @@ -1318,9 +1318,16 @@ eww-mode ;; desktop support (setq-local desktop-save-buffer #'eww-desktop-misc-data) (setq truncate-lines t) + ;; thingatpt support (setq-local thing-at-point-provider-alist - (append thing-at-point-provider-alist - '((url . eww--url-at-point + (cons '(url . eww--url-at-point) +thing-at-point-provider-alist)) + (setq-local forward-thing-provider-alist + (cons '(url . eww--forward-url) +forward-thing-provider-alist)) + (setq-local bounds-of-thing-at-poi
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 4/29/2024 11:14 AM, Ihor Radchenko wrote: Thanks! I have a small comment on the docstring of `forward-thing-provider-alist' - it refers to `thing-at-point-provider-alist', but the provides here are called with an argument N, unlike the providers in `thing-at-point-provider-alist'. Fixed. I've also added some helper functions for 'forward-thing' and 'bounds-of-thing-at-point' when the "thing" is defined by a text property, and then used those helper functions for EWW and bug-reference-mode. I've lightly tested this (and added a few automated regression tests), but there could be some bugs lurking in here...From ad8db930907cd760142fd6f035d97ce93ce8d850 Mon Sep 17 00:00:00 2001 From: Jim Porter Date: Sun, 28 Apr 2024 21:19:53 -0700 Subject: [PATCH] Allow defining custom providers for more "thingatpt" functions * lisp/thingatpt.el (forward-thing-provider-alist) (bounds-of-thing-at-point-provider-alist): New variables... (forward-thing, bounds-of-thing-at-point): ... use them. (text-property-search-forward, text-property-search-backward) (prop-match-beginning, prop-match-end): Declare. (forward-thing-for-text-property) (bounds-of-thing-at-point-for-text-property): New functions. * lisp/net/eww.el (eww--bounds-of-url-at-point, eww--forward-url): New functions... (eww-mode): ... use them. * lisp/progmodes/bug-reference.el (bug-reference--bounds-of-url-at-point, bug-reference--forward-url): New functions... (bug-reference--init): ... use them. * test/lisp/thingatpt-tests.el (thing-at-point-providers) (forward-thing-providers, bounds-of-thing-at-point-providers): New tests. * etc/NEWS: Announce this change. --- etc/NEWS| 21 +++--- lisp/net/eww.el | 14 +++ lisp/progmodes/bug-reference.el | 22 +- lisp/thingatpt.el | 71 ++--- test/lisp/thingatpt-tests.el| 36 + 5 files changed, 153 insertions(+), 11 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 7efb4110bcd..394f75884c1 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1591,19 +1591,30 @@ of the currently existing keyboards macros using the new mode duplicating them, deleting them, and editing their counters, formats, and keys. -** Miscellaneous +** thingatpt.el --- -*** Webjump now assumes URIs are HTTPS instead of HTTP. -For links in 'webjump-sites' without an explicit URI scheme, it was -previously assumed that they should be prefixed with "http://;. Such -URIs are now prefixed with "https://; instead. +*** New variables and functions for providing custom thingatpt implementations. +The new variables 'bounds-of-thing-at-point-provider-alist' and +'forward-thing-provider-alist' now allow defining custom implementations +of 'bounds-of-thing-at-point' and 'forward-thing', respectively. In +addition, "things" defined by a text property can use the new functions +'bounds-of-thing-at-point-for-text-property' and +'forward-thing-for-text-property' to help implement these providers. --- *** 'bug-reference-mode' now supports 'thing-at-point'. Now, calling '(thing-at-point 'url)' when point is on a bug reference will return the URL for that bug. +** Miscellaneous + +--- +*** Webjump now assumes URIs are HTTPS instead of HTTP. +For links in 'webjump-sites' without an explicit URI scheme, it was +previously assumed that they should be prefixed with "http://;. Such +URIs are now prefixed with "https://; instead. + +++ *** New user option 'rcirc-log-time-format' This allows for rcirc logs to use a custom timestamp format, than the diff --git a/lisp/net/eww.el b/lisp/net/eww.el index 39ea964d47a..adabd8d8d8b 100644 --- a/lisp/net/eww.el +++ b/lisp/net/eww.el @@ -1321,6 +1321,12 @@ eww-mode (setq-local thing-at-point-provider-alist (append thing-at-point-provider-alist '((url . eww--url-at-point + (setq-local bounds-of-thing-at-point-provider-alist + (append bounds-of-thing-at-point-provider-alist + '((url . eww--bounds-of-url-at-point + (setq-local forward-thing-provider-alist + (append forward-thing-provider-alist + '((url . eww--forward-url (setq-local bookmark-make-record-function #'eww-bookmark-make-record) (buffer-disable-undo) (setq-local shr-url-transformer #'eww--transform-url) @@ -1351,6 +1357,14 @@ eww--url-at-point "`thing-at-point' provider function." (get-text-property (point) 'shr-url)) +(defun eww--bounds-of-url-at-point () + "`bounds-of-thing-at-point' provider function." + (bounds-of-thing-at-point-for-text-property 'shr-url)) + +(defun eww--forward-url (n) + "`forward-thing' provider function." + (forward-thing-for-text-property 'shr-url n)) + ;;;###autoload (defun eww-browse-url (url new-window) "Ask the EWW browser to load URL. diff --git a/lisp/progmodes/bug
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 4/12/2024 3:30 PM, Jim Porter wrote: On 4/12/2024 5:41 AM, Ihor Radchenko wrote: Jim Porter writes: That sounds reasonable enough to me; does anyone else have opinions on this? Otherwise, I'll get to work on a patch (though probably not for a couple weeks). It has been a while since the last message in this thread. Jim, may I know if you had a chance to work on the patch? Sorry about that. I'm currently extremely swamped with real life, but most of that should be wrapped up by the end of the month, at which point I'll be able to devote some time to Emacs again. Ihor, Eli: What do you think of the attached patch? I added variables to let modes define custom providers for 'bounds-of-thing-at-point' and 'forward-thing'. (Notably, I avoided adding vars for the 'beginning-of-thing' and 'end-of-thing' functions, since those just call 'bounds-of-thing-at-point' anyway.) If this looks like a reasonable way to go, I'll continue work on this patch by adding entries to 'bounds-of-thing-at-point-provider-alist' and 'forward-thing-provider-alist' in the appropriate places (i.e. wherever we already add to 'thing-at-point-provider-alist', like in EWW).From a0ed62aa42fa47043511ba814cf5ce8419e9d03f Mon Sep 17 00:00:00 2001 From: Jim Porter Date: Sun, 28 Apr 2024 21:19:53 -0700 Subject: [PATCH] Allow defining custom providers for more "thingatpt" functions * lisp/thingatpt.el (bounds-of-thing-at-point-provider-alist) (forward-thing-provider-alist): New variables... (forward-thing, bounds-of-thing-at-point): ... use them. * test/lisp/thingatpt-tests.el (thing-at-point-providers) (forward-thing-providers, bounds-of-thing-at-point-providers): New tests. * etc/NEWS: Announce this change. --- etc/NEWS | 18 +- lisp/thingatpt.el| 35 ++- test/lisp/thingatpt-tests.el | 31 +++ 3 files changed, 74 insertions(+), 10 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 7efb4110bcd..2480f0d096d 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1591,19 +1591,27 @@ of the currently existing keyboards macros using the new mode duplicating them, deleting them, and editing their counters, formats, and keys. -** Miscellaneous +** thingatpt.el --- -*** Webjump now assumes URIs are HTTPS instead of HTTP. -For links in 'webjump-sites' without an explicit URI scheme, it was -previously assumed that they should be prefixed with "http://;. Such -URIs are now prefixed with "https://; instead. +*** New variables for providing custom thingatpt implementations. +The new variables 'bounds-of-thing-at-point-provider-alist' and +'forward-thing-provider-alist' now allow defining custom implementations +of 'bounds-of-thing-at-point' and 'forward-thing', respectively. --- *** 'bug-reference-mode' now supports 'thing-at-point'. Now, calling '(thing-at-point 'url)' when point is on a bug reference will return the URL for that bug. +** Miscellaneous + +--- +*** Webjump now assumes URIs are HTTPS instead of HTTP. +For links in 'webjump-sites' without an explicit URI scheme, it was +previously assumed that they should be prefixed with "http://;. Such +URIs are now prefixed with "https://; instead. + +++ *** New user option 'rcirc-log-time-format' This allows for rcirc logs to use a custom timestamp format, than the diff --git a/lisp/thingatpt.el b/lisp/thingatpt.el index 7896ad984df..d5f71e3c6a8 100644 --- a/lisp/thingatpt.el +++ b/lisp/thingatpt.el @@ -75,6 +75,22 @@ thing-at-point-provider-alist `existing-filename', `url', `email', `uuid', `word', `sentence', `whitespace', `line', `face' and `page'.") +(defvar bounds-of-thing-at-point-provider-alist nil + "Alist of providers to return the bounds of a \"thing\" at point. +This variable can be set globally, or appended to buffer-locally by +modes, to provide functions that will return the bounds of a \"thing\" +at point. The first provider for the \"thing\" that returns a non-nil +value wins. You can use this in much the same way as +`thing-at-point-provider-alist' (which see).") + +(defvar forward-thing-provider-alist nil + "Alist of providers for moving forward to the end of a \"thing\". +This variable can be set globally, or appended to buffer-locally by +modes, to provide functions that will move forward to the end of a +\"thing\" at point. The first provider for the \"thing\" that returns a +non-nil value wins. You can use this in much the same way as +`thing-at-point-provider-alist' (which see).") + ;; Basic movement ;;;###autoload @@ -84,11 +100,16 @@ forward-thing Possibilities include `symbol', `list', `sexp', `defun', `number', `filename', `url', `email', `uuid', `word', `sentence', `whitespace', `line', and `page'." - (let ((forward-op (or (get thing 'forward-op) - (intern-soft (format "fo
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 4/12/2024 5:41 AM, Ihor Radchenko wrote: Jim Porter writes: That sounds reasonable enough to me; does anyone else have opinions on this? Otherwise, I'll get to work on a patch (though probably not for a couple weeks). It has been a while since the last message in this thread. Jim, may I know if you had a chance to work on the patch? Sorry about that. I'm currently extremely swamped with real life, but most of that should be wrapped up by the end of the month, at which point I'll be able to devote some time to Emacs again.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 2/5/2024 7:07 AM, Ihor Radchenko wrote: It would make sense to add a number of alists: - bounds-of-thing-at-point-provider-alist - same for 'forward-op, 'beginning-op, 'end-op. After Emacs have those, we can add Org mode support. That sounds reasonable enough to me; does anyone else have opinions on this? Otherwise, I'll get to work on a patch (though probably not for a couple weeks).
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 11/6/2023 12:11 PM, Ihor Radchenko wrote:
[ Branching to emacs-devel for further input from Emacs devs ]
Jim Porter writes:
This is similar to Emacs bug#66752[1]. It would be nice if
"(thing-at-point 'url)" would return the URL when point is over an Org
link. With this, it's easier to write a function that copies (or browses
to) the URL at point without coding so many special cases.
...
+(defun org--url-at-point ()
+ "`thing-at-point' provider function."
+ (org-element-property :raw-link (org-element-context)))
Supporting thingatpt.el is certainly welcome. However, I have some
doubts about how mature thingatpt.el is.
In particular, I am concerned whether `thing-at-point-provider-alist' is
reliable enough in non-trivial scenarios like when given URL string is
not matching some generic URL regexp.
The nice thing about 'thing-at-point-provider-alist' is that your
provider has absolute control over what to return, so Org's URL provider
could do whatever it wants. As far as I can tell, this code path
completely avoids calling 'bounds-of-thing-at-point' ('botap'). However,
it *would* call 'botap' if point wasn't on an Org link, since it would
fall back to the last condition in 'thing-at-point'. Still, this is what
happens today with no provider, so it's not really any worse than before...
Maybe it would make sense for 'thing-at-point' to have a "(catch
'not-found ...)" form around the loop over
'thing-at-point-provider-alist'. Then Org could definitively say,
"There's no URL at point, no matter what anyone else says".
Looking into the source code of `bounds-of-thing-at-point', I see that
for standard "things" (like url),
`thing-at-point-bounds-of-url-at-point' is used unconditionally. In the
case of Org links, we may have something like [[https://orgmode.org]]
that will not match default URL regexp as is. AFAIU, there is no
documented way to customize the behaviour of `bounds-of-thing-at-point'
and `forward-thing'.
I think it would make sense to add some sort of
'bounds-of-thing-at-point-provider-alist' (that's a mouthful!) that
would let modes override the behavior of 'botap', but I don't think
that's necessary for the narrower purpose of asking, "I want the value
of THING at point, if any."
I also have concerns about Org-specific part of the patch, but the above
is far more important, and we need to discuss it before starting to
consider anything for Org mode.
For better or worse, I mostly modeled this patch on how EWW integrates
with thing-at-point, since that's the only place I saw in the Emacs tree
that did this already.
Re: [PATCH] Add support for 'thing-at-point' to get URL at point
On 11/6/2023 11:45 AM, Jim Porter wrote: This is similar to Emacs bug#66752[1]. It would be nice if "(thing-at-point 'url)" would return the URL when point is over an Org link. With this, it's easier to write a function that copies (or browses to) the URL at point without coding so many special cases. Actually, this code should probably be a bit more selective: is there a good way to tell when an Org link is an absolute URL, as opposed to some relative path or internal target? Maybe we should check 'thing-at-point-uri-schemes'?
[PATCH] Add support for 'thing-at-point' to get URL at point
This is similar to Emacs bug#66752[1]. It would be nice if "(thing-at-point 'url)" would return the URL when point is over an Org link. With this, it's easier to write a function that copies (or browses to) the URL at point without coding so many special cases. Attached is a patch with a regression test for it. Should this also get a NEWS entry? [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-10/msg01628.htmlFrom 6bce84bd28253236eff8ef972ede7daf82f95a71 Mon Sep 17 00:00:00 2001 From: Jim Porter Date: Mon, 6 Nov 2023 11:39:09 -0800 Subject: [PATCH] Add support for 'thing-at-point' to get URL at point * lisp/org.el (thingatpt): Require. (org--url-at-point): New function... (org-mode): ... and add it to 'thing-at-point-provider-alist'. * testing/lisp/test-org.el (test-org/thing-at-point/url): New test. --- lisp/org.el | 10 ++ testing/lisp/test-org.el | 10 ++ 2 files changed, 20 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 4eb6ad0ee..c7ecfc13a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -81,6 +81,7 @@ (require 'calendar) (require 'find-func) (require 'format-spec) +(require 'thingatpt) (condition-case nil (load (concat (file-name-directory load-file-name) @@ -4948,6 +4949,11 @@ The following commands are available: #'pcomplete-completions-at-point nil t) (setq-local buffer-face-mode-face 'org-default) + ;; `thing-at-point' support + (setq-local thing-at-point-provider-alist + (append thing-at-point-provider-alist + '((url . org--url-at-point + ;; If empty file that did not turn on Org mode automatically, make ;; it to. (when (and org-insert-mode-line-in-empty-file @@ -8611,6 +8617,10 @@ there is one, return it." (setq link (nth (1- nth) links) (cons link end) +(defun org--url-at-point () + "`thing-at-point' provider function." + (org-element-property :raw-link (org-element-context))) + ;;; File search (defun org-do-occur (regexp cleanup) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 21b850c03..2fe4477a3 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -3583,6 +3583,16 @@ Foo Bar (org-open-at-point)) nil) + +;;; Thing at point + +(ert-deftest test-org/thing-at-point/url () + "Test that `thing-at-point' returns the URL at point." + (should + (org-test-with-temp-text + "[[https://www.gnu.org/software/emacs/][GNU Emacs]]" + (string= (thing-at-point 'url) "https://www.gnu.org/software/emacs/; + ;;; Node Properties -- 2.25.1
Re: Lazy load of org-protocol
On 2/9/2022 8:46 AM, Max Nikulin wrote: It is not a problem to implement --apply in addition to --arg. [snip] For the purposes of this issue, I think either solution would probably work. It probably depends on what people think on emacs-devel. On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). emacsclient --alternate-editor '' --eval '(message "hi")' But it makes it harder to use it during debugging when -Q -L ~/src/org-mode/lisp options are required. Right, invoking the main Emacs instance as a daemon (i.e. when --alternate-editor is the empty string) works pretty differently from invoking the main Emacs instance directly (i.e. when --alternate-editor is "emacs" or somesuch). In the former case, emacsclient starts "emacs --daemon" and then tries to reconnect to the daemon; in the latter, it just takes the arguments passed to emacsclient and forwards them (well, some of them) to emacs. The end result is that it runs "emacs '(message "hi")'", which isn't correct. It'd be nice to fix the behavior of "--alternate-editor emacs" so it passes the --eval flag along too. This might be tricky though, since the semantics of --eval aren't quite the same for emacs and emacsclient. For emacs, --eval means that just the next argument is Lisp code; for emacsclient, --eval means that *all* subsequent (positional) arguments are Lisp code. In practice though, I don't think fixing this is actually *required* to fix the issue of how org-protocol is handled. It only causes issues for the subset of people who use "--alternate-editor emacs" or something similar. - Jim
Re: Lazy load of org-protocol
On 2/7/2022 6:57 AM, Max Nikulin wrote: Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) You have almost managed to sell this idea to me. However even --apply is just sugar for emacsclient --eval "(apply #'func command-line-args-left)" --arg 1 2 So it is --apply option that may require to write a dedicated function if --arg is not implemented. Another limitation of --apply is that the function must accept string arguments only, no lists or even integers or boolean. Yeah, `--arg' does have greater flexibility in that regard, but it comes at the cost of verbosity and some slight behavioral differences with the equivalent in the main emacs executable. For emacs itself, any elements of `command-line-args-left' that aren't consumed by a function will get opened as files, but I don't think that would be the case with emacsclient. Does this difference matter? Probably not. However, avoiding `command-line-args-left' just feels intuitively "cleaner" to me. Still, I think `--arg' should work and be backwards-compatible, so I don't mind it, even if I prefer the simplicity of `--apply'. On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). - Jim
Re: Lazy load of org-protocol
On 2/6/2022 8:42 AM, Max Nikulin wrote: On 06/02/2022 01:27, Jim Porter wrote: As a result, I think a good first step might be to add support for "--funcall" to emacsclient, just like the regular emacs binary. (The "-f" shorthand won't work though, since emacsclient already uses that for "--server-file"). This would simplify the `message-mailto' case above and would also allow org-protocol to do something similar: emacsclient --funcall org-protocol-capture %u No, --funcall is just a sugar for --eval '(func)' that does not contain arbitrary input, but func has no access to other arguments and it is the real problem. Oh right, of course. The emacsclient case with `(message-mailto \"%u\")' threw me off, but `message-mailto' works differently depending on whether you pass it an arg or not. I think, the solution is to add -arg command to emacs server protocol that pushes its argument to a list and extend -exec command that would make such list available as argv or as `command-line-args-left' for evaluated expression. Of course, emacsclient option parser should be modified as well to support --arg option emacsclient --eval '(func)' --arg 1 2 3 emacsclient --eval '(func)' --arg -- 1 2 3 and maybe even for multiple eval+arg pairs emacsclient --eval '(f1)' --arg 'a1' --eval '(f2)' --arg 'a2' 'a3' I think something like this could work, so long as the arguments can be forwarded correctly in the alternate editor case. If I understand how emacsclient handles --eval, I think that might work, but it would still require writing Lisp functions that know how to handle argv or `command-line-args-left'. I'm also not totally sure how safe/sensible that is when the arguments aren't from the invocation of emacs itself, but from emacsclient (and thus, the args could be updated multiple times throughout a session). It probably wouldn't actually break anything, but it does seem a bit surprising to me... Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) This would work effectively like how I momentarily thought --funcall works. Then you could say: emacsclient --apply org-protocol-capture %u # or ... emacs --apply org-protocol-capture %u This would also mean that the `message-mailto' function from Gnus doesn't need to care about `command-line-args-left' anymore, which would simplify it somewhat. And this could be useful in general for programmatically interacting with Emacs, since users would be able to pass arbitrary strings to Emacs Lisp functions without having to worry (as much) about sanitizing the strings first. The proper place to discuss idea is emacs-devel list, but I am afraid that without a patch it will be just buried. I don't know if an actual patch would be a strict prerequisite for posting to emacs-devel, but it's probably wise to have a clear, detailed proposal first. I think it's easier to get everyone on board with an idea if it's easy for them to see how all the details work up-front. - Jim
Re: Lazy load of org-protocol
On 2/5/2022 3:54 AM, Max Nikulin wrote: I would prefer to avoid (require 'org-protocol) in emacs init file and to postpone loading till invocation of emacsclient with org-protocol URI. The problem is a hack in org-protocol. URIs are actually treated as (relative) file names and magic is achieved in an advice for `server-visit-files' function. So the advice must be installed in advance. My first idea was to avoid such magic and to create autoload function org-protocol-from-argv with body similar to that advice. If it were possible to get arguments from `command-line-args-left' then invocation would look like emacsclient --eval '(org-protocol-from-argv)' 'org-protocol:/store-link?url=u1=t1' Unfortunately it is against design of emacs server protocol. If --eval option is given than everything other is considered as independent expressions. At the lower level there is no way to transfer `argv` as a list from client to server process. I've thought a bit about how to improve this too. One further issue with the current implementation is that when emacsclient invokes the alternate editor (usually to start the "main" emacs instance), org-protocol: links no longer work correctly. That's because only the emacsclient itself (through `server-visit-files') knows what to do with them. I think the problem really starts in emacsclient's command line handling. You can see this in other situations too. For example, Emacs can be configured as your system's mailto: URL handler. (The file etc/emacsclient-mail.desktop in the Emacs repo does this.) The command to use for a new Emacs instance is simple: emacs -f message-mailto %u However, doing this for emacsclient is harder: emacsclient --alternate-editor= --create-frame --eval "(message-mailto \\"%u\\")" There's no problem with "--alternate-editor=" and "--create-frame", but the fact that emacsclient requires evaling the function call that way is: if %u holds a string with quotation marks, this will break, and worse, could even result in arbitrary code being executed. (In practice, this is probably rare, since URLs are generally URL-encoded, and so don't have literal quotes in them.) As a result, I think a good first step might be to add support for "--funcall" to emacsclient, just like the regular emacs binary. (The "-f" shorthand won't work though, since emacsclient already uses that for "--server-file"). This would simplify the `message-mailto' case above and would also allow org-protocol to do something similar: emacsclient --funcall org-protocol-capture %u Then, so long as `org-protocol-capture' has an autoload, this would Just Work, and org-protocol.el would be lazily loaded. Hopefully, this could also be forwarded onto the alternate editor so that when the user open an org-protocol: URL when Emacs is closed, it still handles the URL correctly. That said, in the short term, you could try out something like: emacsclient --eval "(org-protocol-capture \\"%u\\")" Of course, that has the quoting issues I mentioned above, but it could be helpful for developing a proof of concept. - Jim
Re: Suggestion: convert dispatchers to use transient
On 2/3/2022 1:30 PM, Tim Cross wrote: Is the transient.el included in Emacs 28 the same as the one on GNU ELPA? Currently, yes. They're both 0.3.7. However, that could obviously change in the future (e.g. a user on 28.1 would likely have transient 0.3.7, though GNU ELPA might have transient 0.3.8 if it were released one day). I'm assuming it is, but I have to admit I'm still not 100% clear on how Emacs handles the situation where you use a library that is both built-in and available in ELPA. Does Emacs use the latest version available or does it use the built-in version until you explicitly select the ELPA versions? Emacs will use the built-in version of a package provided that package meets the version requirements. For the version of Org Mode that comes with Emacs, it would always use the built-in transient (largely because maintainers wouldn't do it any other way). If you download a newer Org version from GNU ELPA, I believe it checks the package metadata and then will fetch transient from GNU ELPA as well if the built-in version is too old. (I haven't looked at the code to verify this, but it's how Eglot worked when I installed it. Eglot wants newer versions of eldoc, xref, project, etc than Emacs 27.2 provides, so package.el automatically installs them when installing Eglot.) - Jim
Re: Suggestion: convert dispatchers to use transient
On 2/3/2022 2:07 AM, Tim Cross wrote: After 28.0 is released, if transient is a GNU ELPA package, we can probably just make it an org dependency and Emacs 26.x and 27.x should be able to install and run it (would need to be verified). The transient package is on GNU ELPA already[1], and based on its package metadata[2], supports Emacs 25.1+, so I don't think there should be any compatibility concerns (at least not with the availability of transient; maybe there are other reasons that dispatchers shouldn't change without an option to go back). - Jim [1] https://elpa.gnu.org/packages/transient.html [2] https://github.com/magit/transient/blob/440a341831398b825dc2288a10821cf7be1999ca/lisp/transient.el#L9
Re: "Orgdown", the new name for the syntax of Org-mode
On 11/28/2021 11:46 AM, Karl Voit wrote: At this year's EmascsConf, I had a 12 minute video where I explain why we do need a different name for the syntax of Org-mode in contrast to the Elisp implementation of GNU/Emacs Org-mode. I would like you to read my rationale and motivate you to use the term "Orgdown" for the syntax and "Orgdown1" for the first (very basic) level of Orgdown syntax elements. I agree that it's useful to distinguish the files/syntax from the *mode*, which contains many functions for doing things with those files. For what it's worth (perhaps not much), I've always referred to the syntax/file format as simply "Org"; for example, "I put my notes into an Org file." This is by analogy with most of the other Emacs major modes for editing files. I write Python in `python-mode', I write C++ in `c++-mode', I write text files in `text-mode', and so on. Maybe "Org" isn't distinct enough though. People unfamiliar with Org-Mode might confuse "Org" with "org charts" or some other use of the word. Still, if we look to other tools that can read the same files as Org-Mode, they tend to be called things like "Organice", not "Orgmodeanice". :) - Jim
Re: [PATCH] Improve org-mouse support for checkboxes
On 9/25/2021 10:58 PM, Bastien wrote: I applied the patch adding the TINYCHANGE cookie, since the assignment process isn't done yet. Can you check with copyright-cl...@fsf.org if it will be done anytime soon? Hm, it should be done, since I received confirmation from the copyright clerk on the 15th. I think I might be in the database as "James" though; that caused a similar hiccup when contributing to Emacs too.
Re: DONE headlines take a different color
On 9/19/2021 9:09 AM, Giovanni Gigante wrote: As per the subject: TODO states mantain the headline color (as expected), but DONE states change it (not expected). As shown in lines 2, 5, 8, 11, 14 of the following screenshot (emacs 27.2 on MacOS launched with -q, org mode 9.4.4): I believe this is the result of `org-fontify-done-headline', which defaults to t as of e360cd8f3a from Feb 2020. - Jim
Re: [PATCH] Improve org-mouse support for checkboxes
On 9/18/2021 1:54 PM, Samuel Wales wrote: thanks for this. if tests are written, might be useful to include the case where half-checked are parents. I tested manually, and this behaves how I'd expect; not surprising, since it just calls `org-toggle-checkbox'. Maybe there's an argument that parent checkboxes shouldn't be clickable in the first place though. I don't think you can call `org-toggle-checkbox' on parent checkboxes (or if you can, I'm not sure what the trick is). My patch doesn't change that though, aside from having half-checked boxes be clickable in general. I could look into writing some automated tests for this, but I don't see any existing ones for org-mouse, and I'm not familiar with simulating mouse events for Emacs tests.
[PATCH] Improve org-mouse support for checkboxes
While trying out `org-mouse', I noticed two semi-related issues with
checkboxes. First, intermediate-state checkboxes (like [-]) aren't
clickable. Second, if the checkboxes are inside a block and the theme
gives the block a background color, the block's background is removed
behind the checkbox. To see both of these in action:
$ cat file.org
* Regular
- [X] Checked.
- [-] Half-checked.
- [ ] Not checked.
* In block
#+begin_src org
- [X] Checked.
- [-] Half-checked.
- [ ] Not checked.
#+end_src
$ emacs -Q --eval '(progn (setq org-modules '"'"'(org-mouse))
(custom-set-faces '"'"'(org-block ((t :background "green")' file.org
The attached patch fixes both of these issues. For the first problem,
maybe it would be useful to put the regexp for checkboxes in a variable
somewhere so it doesn't get out of sync. I wasn't sure though, so I went
with the simpler solution for now.
My FSF copyright assignment should be on file, but let me know if there
are any issues there.
From b2bd5115a89b9b26107aca4b59e516dc7d64f0cc Mon Sep 17 00:00:00 2001
From: Jim Porter
Date: Sat, 18 Sep 2021 12:22:41 -0700
Subject: [PATCH] org-mouse: Support intermediate-state checkboxes
* lisp/org-mouse.el (org-mode-hook): Use regexp from
`org-set-font-lock-defaults' and set font-lock keywords more robustly.
---
lisp/org-mouse.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org-mouse.el b/lisp/org-mouse.el
index 4471d8e8d..eae6cd98f 100644
--- a/lisp/org-mouse.el
+++ b/lisp/org-mouse.el
@@ -890,8 +890,8 @@ This means, between the beginning of line and the point."
(when (memq 'activate-checkboxes org-mouse-features)
(font-lock-add-keywords
nil
- `(("^[ \t]*\\([-+*]\\|[0-9]+[.)]\\) +\\(\\[[ X]\\]\\)"
- (2 `(face org-checkbox keymap ,org-mouse-map mouse-face
highlight) t)))
+ `(("^[ \t]*\\(?:[-+*]\\|[0-9]+[.)]\\)[
\t]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \t]*\\)?\\(\\[[- X]\\]\\)"
+ (1 `(face nil keymap ,org-mouse-map mouse-face highlight)
prepend)))
t))
(defadvice org-open-at-point (around org-mouse-open-at-point
activate)
--
2.25.1
Re: [PATCH] Rename headline to heading
On 8/15/2021 4:17 PM, Tim Cross wrote: At some point, your transition period will end. If it isn't with the transition to v9.5, it will be the transition to 9.6. At this point, all of the issues you point out will still exist. There will still be people who are running multiple versions, there will still be people who failed to read or comprehend the impact of the change. All that the transition does is delay the pain point while adding additional complexity to the code base. Admittedly, in this case, the additional complexity is very small. I think it does more than *just* delaying the pain. It's true that the transition period will end, and any users who haven't updated their configs by then will have a broken config. However, some percentage of users will upgrade Org, see the warning, fix their configs (perhaps not immediately, but in the next few weeks), and continue on with minimal pain. Of course, I'm sure most users would make the necessary change even without a transition period, but the transition period gives users a bit more flexibility in determining when to update their configs. In any case, if Org were to add an informative message about this change, `org-capture-upgrade-templates' seems to me a reasonable place to do it since it's already doing this for other obsolete types. In fact, looking at the commit history, that function was added in Feb 2017 (in commit 0f1b5ec496), so perhaps it's been long enough that the old datetree migration could be removed entirely and be replaced with this new headline -> heading migration. That would have the net effect of *reducing* the total amount of compatibility code. That said, this isn't a critical issue for me either way. I keep Emacs and Org pretty up to date so I shouldn't have a problem when the time comes to make this change in my config. - Jim
Re: [PATCH] Rename headline to heading
On 8/14/2021 3:54 PM, Tim Cross wrote: I'm not convinced a transition period will help in this case. At some point, users will need to update their capture templates regardless. Provided this impact is clearly outlined in the NEWS.org file (I think there should be a specific reference to capture templates added in the patch to NEWS.org) and provided this change is applied to the next release only, no transition period is necessary. I think having a transition period would be helpful here. First, this helps to account for users who may run multiple versions of Emacs with the same config. This could happen for a few reasons, such as running on different revisions of a GNU/Linux distribution, or even just because the user is testing out the latest/next version of Emacs. In addition, a transition period makes it easy to inform users about what they need to do to upgrade. Without any compatibility code, the error message (likely) won't be very helpful, whereas even some minimal compatibility code could tell the user what edits to make to their config. While everyone *should* read the manual/NEWS, it's easy to miss things sometimes, and errors like this can be non-obvious, especially if the compatibility issue isn't directly in the user's config, but in some other third-party package. As such, I think it would be nice to have a transition period of at least one Emacs version. Beyond that, I don't see any problems with excising old compatibility code. As you say, users will have to upgrade at *some* point. - Jim
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
On 5/1/2021 11:09 PM, Bastien wrote:
With `electric-indent-mode' being activated by default in Emacs, the
current behavior is that RET after a headline moves the point below
the beginning of this headline, not the beginning of the line, which
might surprise users.
Indentation is quite sensitive: what do you think of setting a new
default value of nil for `org-adapt-indentation' in Org 9.5?
I much prefer the current behavior as of 9.4.5. I'll try to explain my
reasoning. Of course like anyone, I'm biased, and got used to indenting
the text under a heading (pre-9.4) simply because that's where it ends
up if I hit TAB; in most other modes, TAB indents a line to where it
"should" be, so I reasoned that text under a heading should be indented.
Visually, I find indented text easier to scan. When my org document is
fully-expanded, I can still quickly glance at the left margin to see
when the outline level changes. It's much harder for me to do so when
there's a bunch of text that's flush with the left margin.
`org-indent-mode' can also do this, but I took to heart the Org Mode
motto ("Your life in plain text"): I try to ensure my org files look as
similar as possible regardless of whether they're opened in Emacs or a
plain text editor. Hence, I put the indentation in the actual org file
(and use `auto-fill-mode' to wrap the text)[1]. This makes it easier for
me to send a non-Emacs-using colleague one of my org files while
ensuring it's (somewhat) readable for them.
Finally, as someone who primarily uses Emacs to write software, I find
the current behavior to be more consistent with the other modes I use
most often. In all programming modes I'm familiar with, hitting RET will
create a new line, indented to the appropriate depth. For a
whitespace-dependent language like Python, this is really the *maximum*
depth that would make sense.
However, compared to Org Mode, python-mode has an advantage: if I hit
RET and the indentation isn't what I want (e.g. I was writing an `if'
block and now I'm done with it), I can hit TAB repeatedly to cycle
indentation levels. Org Mode does this when you've typed the "* " for a
heading (or plain list), but not for a blank line. If I'm typing some
text below a heading and hit RET to write some more, I might realize
that I *actually* want a new heading. I could try to type "* ", but as
I'm already indented, Org Mode rightly treats that as a plain list.
Currently, I just hit undo and then try again with C-RET to make a new
heading, but it might be nice to allow cycling indent levels on an
otherwise-empty line.
This reasoning might not apply for users who primarily use Emacs to edit
text documents, as I'm sure the indentation logic there is different
from editing source code. In that case, you could perhaps say that
`org-adapt-indentation' == t is for programmers, and == nil for writers. :)
Ultimately, I'm not sure this will convince anyone who disagrees, and
I'm not even sure my *goal* is to convince people (so long as I'm still
able to configure things the way I like). I just wanted to provide a
perspective from someone on the other side of the fence.
- Jim
[1] This doesn't quite work for links specified like [[url][title]], but
I see that as just a minor hiccup.
