Before storing a link to a contact, actually check that the element at point is
a contact.
This calls the same matcher that is used by ‘org-contacts-db’ to see if the
current element is indeed a contact.
Hi,
Here's a small patch for org-contacts.el.
Be well,
Joseph
From 80365905c9fd342e25ac529dcf0849e4cf90af8c Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sun, 16 Jul 2023 16:13:14 -0700
Subject: [PATCH] Fix: Don't try to store link above first heading
Previously, org-contacts-link-store attempted to store a link when
point was above the first heading, but signalled an error after
(org-get-heading t t t t)
returned nil. Now, org-contacts-link-store does not attempt to handle
storing links above the first heading.
BTW, here's another cosmetic patch. It fixes the following:
- Remove some redundant dependencies (already satisfied by Emacs-27.1).
- Fix a too-wide docstring.
- Use `;;` for comments because `;;;` is for section headers.
Stefan
Hi Miles,
AFAICT the copyright status of org-contacts is now cleared (Michael
Strey's paperwork is done), so we could add it to GNU ELPA.
The only thing missing AFAIK is to change the `copyright` line as in the
patch below which also fixes the output of `git status` after installing
the package.
Stefan
9:67: error: Package gnus is not installable.
9:80: warning: An explicit dependency on cl-lib <= 1.0 is not needed on Emacs >= 24.3.
634:0: warning: Private functions generally should not be autoloaded.
641:0: warning: Private functions generally should not be autoloaded.
645:19: error: You should depend on (emacs "25.1") or the seq package if you need `seq-find'.
673:9: error: You should depend on (emacs "27.1") if you need `org-show-all'.
674:9: error: You should depend on (emacs "25.1") if you need `font-lock-ensure'.
680:0: warning: Private functions generally should not be autoloaded.
684:19: error: You should depend on (emacs "25.1") or the seq package if you need `seq-find'.
699:3: error: You should depend on (emacs "26.1") if you need `when-let*'.
766:8: warning: Closing parens should not be wrapped onto new lines.
788:0: error: "org-completing-read-date" doesn't start with package's prefix "org-contacts".
988:13: error: You should depend on (emacs "25.1") if you need `if-let'.
1060:0: error: "erc-nicknames-list" doesn't start with package's prefix "org-contacts".
1290:0: warning: Private functions generally should not be autoloaded.
> #+begin_src emacs-lisp
> (defun org-contacts-org-complete-function ()
> "Function used in `completion-at-point-functions' in `org-mode' to complete @name."
> (when-let* ((bounds (bounds-of-thing-at-point 'symbol))
> (begin (1- (car bounds)))
> (end (cdr bounds))
> (symbol (buffer-substring-no-properties begin end))
> (org-contacts-prefix-p (string-prefix-p "@" symbol))
> ;; (prefix (substring-no-properties symbol 1 nil))
> )
> (when org-contacts-prefix-p
> (list begin
> end
> (completion-table-dynamic
> (lambda (_)
> (mapcar
> (lambda (contact) (plist-get contact :name))
> (org-contacts--all-contacts))))))))
> #+end_src
This gives a `begin..end` region which presumably includes `@`.
Does (plist-get contact :name) return names that start with `@`?
If not, the completion will never match.
> And test with execute following ~add-hook~ in org-mode buffer or
> emacs-lisp-mode buffer:
In emacs-lisp-mode, `@` has symbol syntax, so
(bounds-of-thing-at-point 'symbol)
will include `@` in the returned region, whereas in Org mode
`@` seems to have punctuation syntax so the `@` will not be included in
the returned region.
Maybe instead of `bounds-of-thing-at-point` you want to use something
less "magic", like (skip-chars-backward "[:alnum:]@").
> I found ~org-contacts-org-complete-function~ returned a special value:
>
> #+begin_example
> #f(compiled-function (string pred action) #<bytecode -0x9e1a398d61d3acb>)
> #+end_example
I can't see any way M-: (org-contacts-org-complete-function) RET
can return the above value. So I suspect a "pilot error".
This looks like the 3rd value in the returned list (i.e. the value
returned by `completion-table-dynamic`).
> #+begin_src emacs-lisp
> (defun org-contacts-org-complete-function ()
> "Function used in `completion-at-point-functions' in `org-mode' to complete @name."
> (when-let* ((bounds (bounds-of-thing-at-point 'symbol))
> (begin (1- (car bounds)))
> (end (cdr bounds))
> (symbol (buffer-substring-no-properties begin end))
> (org-contacts-prefix-p (string-prefix-p "@" symbol))
> ;; (prefix (substring-no-properties symbol 1 nil))
> )
> (when org-contacts-prefix-p
> (list begin
> end
> (completion-table-dynamic
> (lambda (_)
> (mapcar
> (lambda (contact) (plist-get contact :name))
> (org-contacts--all-contacts))))))))
> #+end_src
This gives a `begin..end` region which presumably includes `@`.
Does (plist-get contact :name) return names that start with `@`?
If not, the completion will never match.
> And test with execute following ~add-hook~ in org-mode buffer or
> emacs-lisp-mode buffer:
In emacs-lisp-mode, `@` has symbol syntax, so
(bounds-of-thing-at-point 'symbol)
will include `@` in the returned region, whereas in Org mode
`@` seems to have punctuation syntax so the `@` will not be included in
the returned region.
Maybe instead of `bounds-of-thing-at-point` you want to use something
less "magic", like (skip-chars-backward "[:alnum:]@").
> #+begin_src emacs-lisp
> (add-hook 'completion-at-point-functions 'org-contacts-org-complete-function nil 'local)
> #+end_src
> I have get response from Strey, he said he has requested FSF for
> signing paperwork, should be ready in days.
In the mean time, here's a patch which addresses most of the compiler
warnings I got. It also adds a `Version:` since that'll be necessary
for the package to be released on GNU ELPA. And it furthermore adds
a few FIXMEs which you might want to look at.
Stefan
