Bookmark handler not recognized
publicimageltd opened this issue · 5 comments
I have bookmarks with a custom handler. The property is well defined, it has a function symbol as its value. But if I call `counsel-bookmarks' with ivy-rich enabled, it displays the bookmark type "NOFILE." I expect, however, the first part of the symbol's name.
Here is the relevant configuration part:
(defun jv/ivy-rich-bookmark-name (candidate)
(car (assoc candidate bookmark-alist)))
(plist-put ivy-rich-display-transformers-list
'counsel-bookmark
'(:columns
((ivy-rich-bookmark-type)
(jv/ivy-rich-bookmark-name (:width 40))
(ivy-rich-bookmark-info))))
It all works well expect that non-standard bookmarks are not handled well.
I think it has something to do with `ivy-rich-bookmark-value'. Look at the following:
ELISP> bookmark-alist
(("notmuch: gestern"
((handler . notmuch-bookmarks-jump-handler)
(filename . "date:yesterday")
(major-mode . notmuch-tree-mode)
(buffer-name . "*notmuch-tree-date:yesterday*")
(annotation)
(position)
(defaults "notmuch: " "*notmuch-tree-date:yesterday*")))
ELISP>(ivy-rich-bookmark-value "notmuch: gestern" 'handler)
nil
Shouldn't the value be `notmuch-bookmarks-jump-handler' instead?
It looks something weird of you bookmark-alist
. The content of the bookmark should be
("notmuch: gestern"
(handler . notmuch-bookmark-jump-handler)
(filename . "date:yesterday")
(major-mode . notmuch-tree-mode)
(buffer-name . "*notmuch-tree-date:yesterday*")
(annotation)
(position)
(defaults "notmuch: " "*notmuch-tree-date:yesterday*"))
Note the parentheses surrounding after "notmuch: gestern".
Thanks for having a look at it. It's right, there was a layer of parentheses too much (even though jumping to these malformed records works perfectly, but that is probably another story). So I reconstructed a bookmark object with the format you suggested above, but no avail. It does not work with your example, either. See:
ELISP> (ivy-rich-bookmark-value '("notmuch: gestern"
(handler . notmuch-bookmark-jump-handler)
(filename . "date:yesterday")
(major-mode . notmuch-tree-mode)
(buffer-name . "*notmuch-tree-date:yesterday*")
(annotation)
(position)
(defaults "notmuch: " "*notmuch-tree-date:yesterday*")) 'handler)
nil
ELISP> (bookmark-prop-get '("notmuch: gestern"
(handler . notmuch-bookmark-jump-handler)
(filename . "date:yesterday")
(major-mode . notmuch-tree-mode)
(buffer-name . "*notmuch-tree-date:yesterday*")
(annotation)
(position)
(defaults "notmuch: " "*notmuch-tree-date:yesterday*")) 'handler)
notmuch-bookmark-jump-handler
It took me some time to remind the old codes....😬
When you call ivy-rich-bookmark-value
, you are expected to pass the original ivy
candidate. In this case, it's "notmuch: gestern"
. So
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (ivy-rich-bookmark-value "notmuch: gestern" 'handler)
notmuch-bookmark-jump-handler
ELISP>
ivy-rich-bookmark-type
uses this function to get the handler of the bookmark to format it into type info, i.e.
ELISP> (ivy-rich-bookmark-type "notmuch: gestern")
#("NOTMUCH " 0 8
(face font-lock-keyword-face))
About your original post, jv/ivy-rich-bookmark-name
seems trying to get the bookmark name. If "notmuch: gestern"
is what you want, you can use (ivy-rich-candidate)
to get it (the original candidate name). So you may get something like this
given
counsel-bookmark
(:columns ((ivy-rich-bookmark-type)
(ivy-rich-candidate)
(ivy-rich-bookmark-info)))
About ivy-rich-bookmark-info
, in this case the filename is expanded to true name which maybe not being expected. Since I'm not using notmuch
, if you have any suggestions, don't hesitate to let me know.
Thanks, that's it! Using ivy-rich-candidate
solves the problem. As to the file expansion, I redefined ivy-rich-bookmark-info
so that it only expands the filename if it points to an existing file, which makes sense to me:
(defun ivy-rich-bookmark-info (candidate)
(let ((filename (ivy-rich-bookmark-filename candidate)))
(cond (filename
(cond ((null filename)
"")
((file-remote-p filename)
candidate)
;; CHANGES BEGIN HERE:
((file-exists-p filename) (file-truename filename))
(t filename))))))
Works perfectly.
Glad that helped. I've pushed it to master just now, so you don't need to modify your own after you update it from ELPA.