[PATCH] org-eldoc: Fix compatibility with Emacs 28
James N. V. Cash writes: > Kyle Meyer writes: > >> Basil L. Contovounesios writes: >>> How involved would it be to make org-eldoc work in >>> non-"backwards-compatibility" mode? >> >> I think we can do that, while still supporting Org's minimum Emacs >> version, by following python.el. Here's what it does: >> ... >> >> ... org-eldoc-documentation-function's signature could be changed to >> ( _ignored), like python-eldoc-function's. > > This makes the most sense to me; I missed that the default documentation > strategy also allows the function to ignore the callback & just return a > docstring directly. All right, thanks. Here's that in patch form. I briefly tested with Emacs 26, 27, and 28, and things seemed to work fine (though I'm not an org-eldoc user). I'll plan to apply it in a day or two unless there are objections. -- >8 -- Subject: [PATCH] org-eldoc: Fix compatibility with Emacs 28 * contrib/lisp/org-eldoc.el (org-eldoc-documentation-function): Accept and ignore additional arguments for compatibility with Emacs 28. (org-eldoc-load): Use add-function to register org-eldoc-documentation-function for Emacs versions 25 through 27, as documented in eldoc-documentation-function. See Emacs's fd020a2931 (eldoc: modify `eldoc-documentation-function' using `add-function', 2014-12-05) and c0fcbd2c11 (Expose ElDoc functions in a hook (Bug#28257), 2020-02-25) for more information on the Emacs 25 and Emacs 28 changes, respectively. --- contrib/lisp/org-eldoc.el | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el index 72b10a1fb..b89eb0918 100644 --- a/contrib/lisp/org-eldoc.el +++ b/contrib/lisp/org-eldoc.el @@ -127,7 +127,7 @@ (declare-function css-eldoc-function "css-eldoc" ()) (declare-function php-eldoc-function "php-eldoc" ()) (declare-function go-eldoc--documentation-function "go-eldoc" ()) -(defun org-eldoc-documentation-function () +(defun org-eldoc-documentation-function ( _ignored) "Return breadcrumbs when on a headline, args for src block header-line, calls other documentation functions depending on lang when inside src body." (or @@ -161,11 +161,17 @@ (defun org-eldoc-documentation-function () (defun org-eldoc-load () "Set up org-eldoc documentation function." (interactive) - (if (boundp 'eldoc-documentation-functions) - (add-hook 'eldoc-documentation-functions - #'org-eldoc-documentation-function nil t) -(setq-local eldoc-documentation-function - #'org-eldoc-documentation-function))) + ;; This approach is taken from python.el. + (with-no-warnings +(if (null eldoc-documentation-function) + ;; Emacs<25 + (setq-local eldoc-documentation-function + #'org-eldoc-documentation-function) + (if (boundp 'eldoc-documentation-functions) + (add-hook 'eldoc-documentation-functions + #'org-eldoc-documentation-function nil t) + (add-function :before-until (local 'eldoc-documentation-function) + #'org-eldoc-documentation-function) ;;;###autoload (add-hook 'org-mode-hook #'org-eldoc-load) base-commit: e62ca4a1bf576a2c498f47536d3f12cd698e3ac0 -- 2.27.0
Re: Search for an entry expands parent
17.07.2020, 01:42, "Kyle Meyer" :Gt Uit writes: I recently upgraded to org mode version 9.3.6 and the following behavior was introduced: When I search for an entry using C-s, all the parent entries and sub-entries are expanded and stay expanded. Find in https://imgur.com/a/vzEU1zp screenshots of the newly introduced behavior and expected/old behavior.An image is helpful, and some may follow that link, but it's also usefulto include example Org content and a set of steps to reproduce thebehavior you're describing. Based on that link, something like--8<---cut here---start->8---* A** Bsome text** Ctarget search--8<---cut here---end--->8---And then, with all content folded, 'C-s target'.With the default settings in Org 9, the result is* A** B...** Ctarget searchI believe you want the visibility to be like this:* A...** Ctarget searchYou can customize this behavior through org-show-context-detail. Itsounds like you'd prefer `minimal':(setf (alist-get 'isearch org-show-context-detail) 'minimal)Hello, Thanks a lot for the prompt and helpful response. I added the above snippet to the .emacs file and restarted. Did a describe-variable and got the following:"org-show-context-detail is a variable defined in ‘org.el’.Its value is((agenda . local)(bookmark-jump . lineage)(isearch . minimal)(default . ancestors))" However, doing a search still expands all the entries. I downgraded to orgmode v 9.3.1 and still got the same results. I tried on a fresh emacs instance with the only entry in it being setting the org-show-context-detail isearch to minimal and still got the same results (search expands all entries). Is it possible that this is a bug? I'd like to note that I am using emacs v26.3 . Gt Uit
Re: [QUESTION] Re: [PATCH] make org-attach-url download function as an option
> Indeed, as long as org-attach introduced new async actions. Those hooks will > have problem if they requires files is downloading finished. Also > `make-thread' > does not have process sentinel. That's also an problem. > > Does anyone have better idea? You can wrap the call to org-attach-url-function into with-mutex and run hooks in another thread ustilising the same mutex. Note that the heading contents (including :DIR: property), point, current buffer, and window might be changed at the time the hook thread will be called. You will need to perform some sanity checks and potentially cleanup after org-attach-url-function if the heading was modified in some undesired way. The above assumes that org-attach-url-function returns after the file is attached. This might not be the case if org-attach-url-function calls async shell command. This should be either documented or also handled in some way. Best, Ihor stardiviner writes: > Ihor Radchenko writes: > >> I do not know an answer to your question, but would like to point out >> that make-thread will return immidietealy and all the following code >> will run before the download finishes: >> >> (run-hook-with-args 'org-attach-after-change-hook attach-dir) >> (org-attach-tag) >> (cond ((eq org-attach-store-link-p 'attached)... >> >> At least the hooks and org-attach-tag would expect that the file is >> attached already. > > Indeed, as long as org-attach introduced new async actions. Those hooks will > have problem if they requires files is downloading finished. Also > `make-thread' > does not have process sentinel. That's also an problem. > > Does anyone have better idea? > >> >> Best, >> Ihor >> >> stardiviner writes: >> >>> I got solution for async org-attach-url now. Use `make-thread` for async >>> downloading is simple. >>> >>> Here is the code prototype, but it has a problem, seems `apply` part code >>> does >>> not really downloading file. I don't know why. Does anybody knows the >>> reason? >>> >>> #+begin_src diff >>> modified lisp/org-attach.el >>> @@ -110,6 +110,12 @@ (defcustom org-attach-method 'cp >>> (const :tag "Hard Link" ln) >>> (const :tag "Symbol Link" lns))) >>> >>> +(defcustom org-attach-url-function 'url-copy-file >>> + "The download file function to use in org-attach-url." >>> + :type '(choice (const 'url-copy-file)) >>> + :safe #'functionp >>> + :group 'org-attach) >>> + >>> (defcustom org-attach-expert nil >>>"Non-nil means do not show the splash buffer with the attach dispatcher." >>>:group 'org-attach >>> @@ -503,7 +509,12 @@ (defun org-attach-attach (file visit-dir >>> method) >>> ((eq method 'cp) (copy-file file attach-file)) >>> ((eq method 'ln) (add-name-to-file file attach-file)) >>> ((eq method 'lns) (make-symbolic-link file attach-file)) >>> - ((eq method 'url) (url-copy-file file attach-file))) >>> + ((eq method 'url) (make-thread >>> + (lambda () >>> + ;; (url-copy-file file attach-file) >>> + ;; FIXME This seems does not really download file. >>> Don't know why. >>> + (apply org-attach-url-function '(file attach-file))) >>> + "org-attach-url downloading"))) >>>(run-hook-with-args 'org-attach-after-change-hook attach-dir) >>>(org-attach-tag) >>>(cond ((eq org-attach-store-link-p 'attached) >>> #+end_src >>> >>> Bastien writes: >>> Hi, stardiviner writes: > I found when network is bad and slow, or the download file is big, the > org-attach-url will suspend Emacs for a long time. User might have to > cancel > downloading, and start again later. Indeed, this might be annoying. At the same time, it is not unreasonable to expect the user to know what size is the contents he is willing to attach to an Org node. > I hope to make "org-attach-url" download file asynchronously. But function > org-attach-attach hardcoded this function for 'url method. Here is a > patch to > make it into an option. (FWIW, I could not find the patch.) I think you are on the right track when trying to enhance the 'url package. Maybe url-copy-file should be asynchronous and url could provide url-copy-file-synchronously (to mimic the url-retrieve and url-retrieve-synchronously pair)? Until Emacs has a function to copy a URL's contents asynchronously, I'd rather not add this functionality in Org. >>> >>> >>> -- >>> [ stardiviner ] >>>I try to make every word tell the meaning that I want to express. >>> >>>Blog: https://stardiviner.github.io/ >>>IRC(freenode): stardiviner, Matrix: stardiviner >>>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >>> > > > -- > [ stardiviner ] >I try to make every word tell the meaning that I want to express. > >Blog:
Re: [QUESTION] Re: [PATCH] make org-attach-url download function as an option
Ihor Radchenko writes: > I do not know an answer to your question, but would like to point out > that make-thread will return immidietealy and all the following code > will run before the download finishes: > > (run-hook-with-args 'org-attach-after-change-hook attach-dir) > (org-attach-tag) > (cond ((eq org-attach-store-link-p 'attached)... > > At least the hooks and org-attach-tag would expect that the file is > attached already. Indeed, as long as org-attach introduced new async actions. Those hooks will have problem if they requires files is downloading finished. Also `make-thread' does not have process sentinel. That's also an problem. Does anyone have better idea? > > Best, > Ihor > > stardiviner writes: > >> I got solution for async org-attach-url now. Use `make-thread` for async >> downloading is simple. >> >> Here is the code prototype, but it has a problem, seems `apply` part code >> does >> not really downloading file. I don't know why. Does anybody knows the reason? >> >> #+begin_src diff >> modified lisp/org-attach.el >> @@ -110,6 +110,12 @@ (defcustom org-attach-method 'cp >>(const :tag "Hard Link" ln) >>(const :tag "Symbol Link" lns))) >> >> +(defcustom org-attach-url-function 'url-copy-file >> + "The download file function to use in org-attach-url." >> + :type '(choice (const 'url-copy-file)) >> + :safe #'functionp >> + :group 'org-attach) >> + >> (defcustom org-attach-expert nil >>"Non-nil means do not show the splash buffer with the attach dispatcher." >>:group 'org-attach >> @@ -503,7 +509,12 @@ (defun org-attach-attach (file visit-dir >> method) >> ((eq method 'cp) (copy-file file attach-file)) >> ((eq method 'ln) (add-name-to-file file attach-file)) >> ((eq method 'lns) (make-symbolic-link file attach-file)) >> - ((eq method 'url) (url-copy-file file attach-file))) >> + ((eq method 'url) (make-thread >> + (lambda () >> +;; (url-copy-file file attach-file) >> +;; FIXME This seems does not really download file. >> Don't know why. >> +(apply org-attach-url-function '(file attach-file))) >> + "org-attach-url downloading"))) >>(run-hook-with-args 'org-attach-after-change-hook attach-dir) >>(org-attach-tag) >>(cond ((eq org-attach-store-link-p 'attached) >> #+end_src >> >> Bastien writes: >> >>> Hi, >>> >>> stardiviner writes: >>> I found when network is bad and slow, or the download file is big, the org-attach-url will suspend Emacs for a long time. User might have to cancel downloading, and start again later. >>> >>> Indeed, this might be annoying. At the same time, it is not >>> unreasonable to expect the user to know what size is the contents he >>> is willing to attach to an Org node. >>> I hope to make "org-attach-url" download file asynchronously. But function org-attach-attach hardcoded this function for 'url method. Here is a patch to make it into an option. >>> >>> (FWIW, I could not find the patch.) >>> >>> I think you are on the right track when trying to enhance the 'url >>> package. Maybe url-copy-file should be asynchronous and url could >>> provide url-copy-file-synchronously (to mimic the url-retrieve and >>> url-retrieve-synchronously pair)? >>> >>> Until Emacs has a function to copy a URL's contents asynchronously, >>> I'd rather not add this functionality in Org. >> >> >> -- >> [ stardiviner ] >>I try to make every word tell the meaning that I want to express. >> >>Blog: https://stardiviner.github.io/ >>IRC(freenode): stardiviner, Matrix: stardiviner >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: Search for an entry expands parent
Gt Uit writes: > I recently upgraded to org mode version 9.3.6 and the following > behavior was introduced: When I search for an entry using C-s, all the > parent entries and sub-entries are expanded and stay expanded. > > Find in https://imgur.com/a/vzEU1zp screenshots of the newly > introduced behavior and expected/old behavior. An image is helpful, and some may follow that link, but it's also useful to include example Org content and a set of steps to reproduce the behavior you're describing. Based on that link, something like --8<---cut here---start->8--- * A ** B some text ** C target search --8<---cut here---end--->8--- And then, with all content folded, 'C-s target'. With the default settings in Org 9, the result is * A ** B... ** C target search I believe you want the visibility to be like this: * A... ** C target search You can customize this behavior through org-show-context-detail. It sounds like you'd prefer `minimal': (setf (alist-get 'isearch org-show-context-detail) 'minimal)
Default description for abbreviated links
Hello Org,
I like #+LINK keywords because they make documents self-sufficient:
anyone opening my document can follow these links or export the buffer;
they do not need to run some Elisp to add to org-link-parameters.
One thing I don't know how to customize, however, is how these links are
exported when they have no description. Let's say I define this
abbreviation:
#+LINK: bug https://debbugs.gnu.org/
If I jot down references to [[bug:12345]] in my document, these will be
exported as:
https://debbugs.gnu.org/12345;>https://debbugs.gnu.org/12345
Whereas I'd prefer:
https://debbugs.gnu.org/12345;>bug:12345
Looking at org-element-link-parser, I see that this is because the
:contents-begin and :contents-end properties are nil, since they
correspond to an unmatched optional group in org-link-bracket-re.
I could probably customize org-link-parameters, but then my document
would not be self-sufficient anymore. Besides, depending on the
document I might use the same abbreviation for different URLs.
Would it make sense to add a way for abbreviated links with no
description to fallback to LINKKEY:TAG[1] instead of the full URL? If
so, what would be the best way to go about it?
(1) A single variable (e.g. org-link-abbrev-default-description), default
nil, which a user could set to 'key-tag or just 'tag.
(2) A third entry in org-link-abbrev-alist(-local), default nil, which a
user could set to 'key-tag or just 'tag.
(3) Something else (e.g. a new alist).
I've attached a very crude patch for (1): now if I stick this footer in
my Org files:
#+LINK: bug https://debbugs.gnu.org/
# Local variables:
# org-link-abbrev-default-description: key-tag
# end:
Then [[bug:12345]] is exported as
https://debbugs.gnu.org/12345;>bug:12345.
WDYT? If the idea is sound, I will clean up the patch, clarify
docstrings, add :safe predicates and unit tests, and re-submit.
Thank you for your time.
diff --git a/lisp/ol.el b/lisp/ol.el
index 82fc69769..fa0ade8b8 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -255,6 +255,16 @@ See the manual for examples."
(`(,(pred stringp) . ,(pred stringp)) t)
(_ nil
+(defcustom org-link-abbrev-default-description nil
+ "Fallback behaviour for abbreviated links with no description.
+If this is nil, do not set a description; some export backends
+will use the fully expanded link as fallback. If 'key-tag, then
+use the abbreviated form KEY:TAG. If 'tag, then use TAG."
+ :group 'org-link
+ :type '(choice (const :tag "None" nil)
+ (const :tag "KEY:TAG" key-tag)
+ (const :tag "TAG" tag)))
+
(defgroup org-link-follow nil
"Options concerning following links in Org mode."
:tag "Org Follow Link"
@@ -993,6 +1003,16 @@ and then used in capture templates."
if store-func
collect store-func))
+(defun org-link-abbrev-default-desc (link)
+ (save-match-data
+(when (string-match "^\\([^:]*\\)::?\\(.+\\)$" link)
+ (pcase org-link-abbrev-default-description
+ ('nil '(nil nil))
+ ('key-tag
+ (list (match-beginning 1) (match-end 2)))
+ ('tag
+ (list (match-beginning 2) (match-end 2)))
+
(defun org-link-expand-abbrev (link)
"Replace link abbreviations in LINK string.
Abbreviations are defined in `org-link-abbrev-alist'."
diff --git a/lisp/org-element.el b/lisp/org-element.el
index a693cb68d..a82fce52a 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3146,11 +3146,19 @@ Assume point is at the beginning of the link."
;; (e.g., insert [[shell:ls%20*.org]] instead of
;; [[shell:ls *.org]], which defeats Org's focus on
;; simplicity.
- (setq raw-link (org-link-expand-abbrev
- (org-link-unescape
- (replace-regexp-in-string
- "[ \t]*\n[ \t]*" " "
- (match-string-no-properties 1)
+ (let ((link-spec (match-string-no-properties 1))
+ (link-beg (match-beginning 1)))
+ (setq raw-link (org-link-expand-abbrev (org-link-unescape
+ (replace-regexp-in-string
+ "[ \t]*\n[ \t]*" " "
+ link-spec
+ ;; If there is no description, try to find a fallback.
+ (unless contents-begin
+ (pcase-let ((`(,default-beg ,default-end)
+ (org-link-abbrev-default-desc link-spec)))
+ (when default-beg
+ (setq contents-begin (+ link-beg default-beg)
+ contents-end (+ link-beg default-end))
;; Determine TYPE of link and set PATH accordingly. According
;; to RFC 3986, remove whitespaces from URI in external links.
;; In internal ones, treat indentation as a single space.
[1] Or just TAG. If I look at ORG-NEWS for examples, I see a lot of
[[doc:org-symbol][org-symbol]].
Re: [PATCH] Make org-eldoc work with Emacs 28
Kyle Meyer writes: > Basil L. Contovounesios writes: >> How involved would it be to make org-eldoc work in >> non-"backwards-compatibility" mode? > > I think we can do that, while still supporting Org's minimum Emacs > version, by following python.el. Here's what it does: > ... > > ... org-eldoc-documentation-function's signature could be changed to > ( _ignored), like python-eldoc-function's. This makes the most sense to me; I missed that the default documentation strategy also allows the function to ignore the callback & just return a docstring directly.
Search for an entry expands parent
Hello,I recently upgraded to org mode version 9.3.6 and the following behavior was introduced: When I search for an entry using C-s, all the parent entries and sub-entries are expanded and stay expanded.Find in https://imgur.com/a/vzEU1zp screenshots of the newly introduced behavior and expected/old behavior.Please advise on how to resolve.PS: I first asked question on Reddit, https://www.reddit.com/r/orgmode/comments/hps5ey/search_for_an_entry_expands_parent/Gt Uit
