Problem displaying links in vulpea-select-annotate-fn

[Cletip]

Hi :)

It's a pretty specific problem, and 1 I'm having a hard time explaining it and I hope you'll understand with the screenshots, and 2, I really have no idea how to solve it personally (but maybe it's quite simple).

First, the screeshoot (the first one is just to let you know that "emacs" is a link, but as it's part of the title, it's not in blue) :  

So, the texte is exactly this : #+title: Page de Test [[id:20220617105453042719][Emacs]]

The next screeshot is after "vulpea-find" command :

Then, instead of making a long useless description, I think it's enough to say this: when I put a link in a metadata and then use it in the annotation function of vulpea, the rendering is not "clean", because we see the link without... "nice display" ? A "nice display" = just see the description, and not the id + [ and ]. Anyway, I'm sorry I'm really struggling to express myself on this one ^^ but I think you understood the problem.

Do you have any idea how to solve it, and make a "clean" display?

Thanks you (again) for your future answer :)

[d12frosted]

Hey,

I am on the move right now, so can't properly answer your question. But please share the function you use to 'describe' notes in completion. I am pretty sure you need to play with type of extracted metadata (because it looks like you are using the default type - string).

https://github.com/d12frosted/vulpea/blob/f4d3448b6ccdb314c5fe3defea66e750e1371a10/vulpea-note.el#L95-L100

Alternatively you can just extract the title using regexp (e.g. org-link-any-re).

[Cletip]

Thank you for your answer, I immediately found where to look. Thanks to the org-mode parser, I wanted to change "("id" (org-element-property :path el))" by modifying ":path", but to have the description. Well, it's a good thing... figured out that there is none! So, I created a function that, in a string, replaces the org-mode links by their description.

(defun cp/string-with-link-to-string-with-description-of-link (a-string)
    "Take a string with link(s) (org-mode), return the same string, but only with
          the description of link(s)"
    (replace-regexp-in-string "\\(\\[\\[.*\\]\\[\\)\\(.*\\)\\]\\]" "\\2" a-string)
    )

Then I call the function like this: (cp/string-with-link-to-string-with-description-of-link (vulpea-meta-get note cp/vulpea-date)) And it's perfect !

Why not add a type of metadata to have the description of a link/note ?

[d12frosted]

Why not add a type of metadata to have the description of a link/note ?

That's a nice idea. I wonder how to call this type. Maybe link-full? And it could return a plist like (:type :link :description). The :type could be id, https, etc. The :link is either the full link like https:/.... or the id (more useful than id:xyz....). In order to get, say, description you will do: (plist-get (vulpea-note-get-metadata note prop 'link-full) :description).

WDYT?

[Cletip]

I'm not sure how useful it is to send the whole link (path + description). Indeed, the "path" is already returned by an extraction type. The only time I can see it being useful would be for performance issues, where it would be more efficient to extract path+description instead of extracting the path, then the description with another "command" / metadata type.

Anyway, I think it's enough to introduce a simple metadata type that would extract the description of a link. "link-description" for the name maybe ?

All this is just my opinion, do as you like :)

PS : but that : (plist-get (vulpea-note-get-metadata note prop 'link-full) :description) seem sooo clean x)

[d12frosted]

🤔 Actually I think it's better for link type to return everything instead of introducing a new type. But it's a breaking change. Why? Because it's more general and covers all use cases without any performance degradation. But first, I need to consider how many users I break if I change semantics of link type. I can easily fix all my code.

BTW, I've implemented link as a raw link cause I found it more useful for my coding needs. I never needed description because I can always get the up to date title of the link by querying DB. Yeah, less performant, but it covered all my needs :) And there is a shortcut for this: (vulpea-note-title (vulpea-note-meta-get note prop 'note)).

[Cletip]

thinking Actually I think it's better for link type to return everything instead of introducing a new type. But it's a breaking change. Why? Because it's more general and covers all use cases without any performance degradation. But first, I need to consider how many users I break if I change semantics of link type. I can easily fix all my code.

Yes I understand that this is more general. But, on the other hand, if you add a type for the description, you won't have any problem with some changes. But yes, both are equal ^^

BTW, I've implemented link as a raw link cause I found it more useful for my coding needs. I never needed description because I can always get the up to date title of the link by querying DB. Yeah, less performant, but it covered all my needs :) And there is a shortcut for this: (vulpea-note-title (vulpea-note-meta-get note prop 'note)).

Yes ok very practical x)