d12frosted / vulpea Goto Github PK

In cases when user has to perform multiple calls to meta API, it leads to multiple DB calls. While it's not that slow, it should not be like this. Instead we can accept note-or-id.

I was looking for how to use metadata in a good way for performance.

I was thinking about this part
"Functions of interest:

vulpea-meta - function to get metadata from NOTE-OR-ID. In most cases you should not use this function unless performance is important. In this case, take a look at bang functions, e.g. vulpea-meta-get!"

I do believe that in the end, from what I understood from the code, most of the functions boil down to "vulpea-buffer-meta-X" style functions.
So I thought, according to the readme, that there was a difference between the functions. But actually, I think not ^^

I'll post my stack trace below.

This only occurs with my Org-Agenda "today" view, and no other views. The error from org is org-element-at-point: 'org-element-at-point' cannot be used in non-Org buffer #<buffer *Org Agenda*> (org-agenda-mode)

I'm using Vulpea like to update my org-agenda-files list.

You can see my config at https://github.com/DominikMendel/Doom-Emacs
It's a mess at the moment in some spots, and a little outdated from what I'll running. I'll make sure it's up to date tonight, but the Vulpea logic and Org-Agenda logic hasn't changed.

Stack trace

Debugger entered--Lisp error: (error "‘org-element-at-point’ cannot be used in non-Org b...")
  signal(error ("‘org-element-at-point’ cannot be used in non-Org b..."))
  error("`org-element-at-point' cannot be used in non-Org b..." #<buffer *Org Agenda*> org-agenda-mode)
  org-element-at-point(28)
  org-entry-get-with-inheritance("CATEGORY" nil 28)
  org-get-category()
  (let* ((file-name (if buffer-file-name (progn (file-name-sans-extension (file-name-nondirectory buffer-file-name))))) (title (vulpea-buffer-prop-get "title")) (category (org-get-category)) (result (or (if (and title (string-equal category file-name)) title category) ""))) (if (numberp len) (s-truncate len (s-pad-right len " " result)) result))
  vulpea-agenda-category(20)
  (org-eval (vulpea-agenda-category 20))
  (format "%s" (org-eval (vulpea-agenda-category 20)))
  (format " %s %s%s%s" (format "%s" (if (member category-icon '("" nil)) "" (concat category-icon "" (get-text-property 0 'extra-space category-icon)))) (format "%s" (org-eval (vulpea-agenda-category 20))) (if (member time '("" nil)) "" (format "%-20s" (concat time ""))) (format "%s" (if (member extra '("" nil)) "" (concat extra " " (get-text-property 0 'extra-space extra)))))
  eval((format " %s %s%s%s" (format "%s" (if (member category-icon '("" nil)) "" (concat category-icon "" (get-text-property 0 'extra-space category-icon)))) (format "%s" (org-eval (vulpea-agenda-category 20))) (if (member time '("" nil)) "" (format "%-20s" (concat time ""))) (format "%s" (if (member extra '("" nil)) "" (concat extra " " (get-text-property 0 'extra-space extra))))) t)
  org-agenda-format-item(nil "----------------" nil "" nil "08:00")
  org-agenda-add-time-grid-maybe((... ... ... ... ... ... ... ... ... ... ... ... ... ... ...) 1 t)
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  #f(compiled-function () #<bytecode 0x15aad97491556a04>)()
  funcall(#f(compiled-function () #<bytecode 0x15aad97491556a04>))
  (let ((org-agenda-overriding-header '"") (org-agenda-span 'day) (org-agenda-start-day 'nil) (org-agenda-start-on-weekday 'nil) (org-agenda-time-grid '((daily today) (800 1000 1200 1400 1600 1800 2000) "" "----------------")) (org-super-agenda-groups '((:name "Clocked today" :log t) (:name "Scheduled Today" :time-grid t :date today :order 1) (:name "Habbits" :habit t :date today :order 2) (:name "Overdue Deadline" :face error :deadline past :order 3) (:name "Approaching Deadline" :face warning :deadline future :order 4) (:discard (:not (:scheduled past))) (:order-multi (5 (:name "Reviews To-Do" :tag "review") (:name "Previously Scheduled To-Do" :face warning :and ...) (:name "Previously Scheduled Inprogress" :face warning :and ...) (:name "Previously Scheduled In-Review" :face warning :and ...))) (:auto-parent t :order 6) (:discard (:anything t))))) (funcall '#f(compiled-function () #<bytecode 0x15aad97491556a04>)))
  eval((let ((org-agenda-overriding-header '"") (org-agenda-span 'day) (org-agenda-start-day 'nil) (org-agenda-start-on-weekday 'nil) (org-agenda-time-grid '((daily today) (800 1000 1200 1400 1600 1800 2000) "" "----------------")) (org-super-agenda-groups '((:name "Clocked today" :log t) (:name "Scheduled Today" :time-grid t :date today :order 1) (:name "Habbits" :habit t :date today :order 2) (:name "Overdue Deadline" :face error :deadline past :order 3) (:name "Approaching Deadline" :face warning :deadline future :order 4) (:discard (:not ...)) (:order-multi (5 ... ... ... ...)) (:auto-parent t :order 6) (:discard (:anything t))))) (funcall '#f(compiled-function () #<bytecode 0x15aad97491556a04>))))
  org-agenda-run-series("Today view" (((agenda "" ((org-agenda-overriding-header "") (org-agenda-span 'day) (org-agenda-start-day nil) (org-agenda-start-on-weekday nil) (org-agenda-time-grid '(... ... "" "----------------")) (org-super-agenda-groups my-super-group-agenda-today))) (alltodo "" ((org-agenda-overriding-header "") (org-super-agenda-groups my-super-group-alltodo-today))))))
  #f(compiled-function (&optional arg keys restriction) "Dispatch agenda commands to collect entries to the agenda buffer.\nPrompts for a command to execute.  Any prefix arg will be passed\non to the selected command.  The default selections are:\n\na     Call `org-agenda-list' to display the agenda for current day or week.\nt     Call `org-todo-list' to display the global todo list.\nT     Call `org-todo-list' to display the global todo list, select only\n      entries with a specific TODO keyword (the user gets a prompt).\nm     Call `org-tags-view' to display headlines with tags matching\n      a condition  (the user is prompted for the condition).\nM     Like `m', but select only TODO entries, no ordinary headlines.\ne     Export views to associated files.\ns     Search entries for keywords.\nS     Search entries for keywords, only with TODO keywords.\n/     Multi occur across all agenda files and also files listed\n      in `org-agenda-text-search-extra-files'.\n<     Restrict agenda commands to buffer, subtree, or region.\n      Press several times to get the desired effect.\n>     Remove a previous restriction.\n#     List \"stuck\" projects.\n!     Configure what \"stuck\" means.\nC     Configure custom agenda commands.\n\nMore commands can be added by configuring the variable\n`org-agenda-custom-commands'.  In particular, specific tags and TODO keyword\nsearches can be pre-defined in this way.\n\nIf the current buffer is in Org mode and visiting a file, you can also\nfirst press `<' once to indicate that the agenda should be temporarily\n(until the next use of `\\[org-agenda]') restricted to the current file.\nPressing `<' twice means to restrict to the current subtree or region\n(if active)." (interactive "P") #<bytecode -0xfea313bed7e2dda>)(nil "t" nil)
  apply(#f(compiled-function (&optional arg keys restriction) "Dispatch agenda commands to collect entries to the agenda buffer.\nPrompts for a command to execute.  Any prefix arg will be passed\non to the selected command.  The default selections are:\n\na     Call `org-agenda-list' to display the agenda for current day or week.\nt     Call `org-todo-list' to display the global todo list.\nT     Call `org-todo-list' to display the global todo list, select only\n      entries with a specific TODO keyword (the user gets a prompt).\nm     Call `org-tags-view' to display headlines with tags matching\n      a condition  (the user is prompted for the condition).\nM     Like `m', but select only TODO entries, no ordinary headlines.\ne     Export views to associated files.\ns     Search entries for keywords.\nS     Search entries for keywords, only with TODO keywords.\n/     Multi occur across all agenda files and also files listed\n      in `org-agenda-text-search-extra-files'.\n<     Restrict agenda commands to buffer, subtree, or region.\n      Press several times to get the desired effect.\n>     Remove a previous restriction.\n#     List \"stuck\" projects.\n!     Configure what \"stuck\" means.\nC     Configure custom agenda commands.\n\nMore commands can be added by configuring the variable\n`org-agenda-custom-commands'.  In particular, specific tags and TODO keyword\nsearches can be pre-defined in this way.\n\nIf the current buffer is in Org mode and visiting a file, you can also\nfirst press `<' once to indicate that the agenda should be temporarily\n(until the next use of `\\[org-agenda]') restricted to the current file.\nPressing `<' twice means to restrict to the current subtree or region\n(if active)." (interactive "P") #<bytecode -0xfea313bed7e2dda>) (nil "t" nil))
  org-agenda(nil "t" nil)
  (call-interactively (org-agenda nil "t" nil))
  eval((call-interactively (org-agenda nil "t" nil)) t)
  eval-expression((call-interactively (org-agenda nil "t" nil)))
  eval((eval-expression (car (read-from-string #("(call-interactively (org-agenda nil \"t\" nil))" 0 39 (ws-butler-chg chg) 39 40 (ws-butler-chg delete) 40 45 (ws-butler-chg chg))))) t)
  evil-ex(nil)
  funcall-interactively(evil-ex nil)
  call-interactively(evil-ex nil nil)
  command-execute(evil-ex)

I see in many places (vulpea, vino, environment) I have the following pattern:

(org-make-link-string
          (concat "id:" (vulpea-note-id note))
          (vulpea-note-title note))

Would be lovely to have an utility for that.

It would be convenient and powerful to be able to 'refactor' tag names across all notes / dailies. The org-roam issue here may be relevant. Is this something that would make sense for vulpea?

I often need to do something inside note buffer, when the only thing I have is id, so I have to get the file first and then use vulpea-with-file. This could be combined into one function.

Another thing to consider, if id represents a note with level > 0, point should be at the heading with given id. Probably this is this the main reason to have vulpea-with-note function.

Since vulpea-note-id is mandatory in vulpea, and file-level ids are optional in org-mode, it causes issues if properties block is ommitted in template. User might put it in every template, or configures automatic id assigment, but vulpea could also leverage this issue by placing this block automatically.

I'm using vulpea to speed up my org-agenda, and I found I have to install it like this in order to have it work:

(use-package! vulpea
  :demand t
  :hook ((org-roam-db-autosync-mode . vulpea-db-autosync-enable)))

Else I get the following error when opening a note:

let*: Symbol’s function definition is void: vulpea-buffer-tags-get

Hi! Yes, it's me again x)

I wanted to know if it was possible to visualize the note selected during the vulpea-find and vulpea-insert commands.
Indeed, when you do org-roam-node-find and org-roam-node-insert, you can choose the desired node of course, but the current buffer teleports instantly to the node so you can immediately know which one it is.

I find this feature really useful, and it can save a lot of time if some notes look similar in the title.

Will it be possible to add a variable to have this feature?

I looked in org-roam, and I think the function that allows this feature would be "org-roam-node-read", but I don't see exactly how it does it.
Also, I'm not sure if the implementation with org-roam is as efficient/simple with vulpea.
I'm even less sure, because I haven't looked long and you know vulpea much better than I do, but maybe the "vulpea-select-from" function should be modified? I hope I don't offend you by saying this sentence, sorry if it offended you x). I'm just giving you some hints ^^

Thanks you (again) in advance for your answer.

See explanation in this thread.

Basically, the following implementation works 1.55 times faster than the current implementation:

(defun vulpea-db-query-by-links-some (destinations)
  "Query a list of `vulpea-note' from database.

Only notes that link to at least one destination from the list of
DESTINATIONS are returned."
  (emacsql-with-transaction (org-roam-db)
    (vulpea-db-query-by-ids
     (seq-map
      #'car
      (org-roam-db-query
       (format "select distinct source from links where dest in %s"
               (emacsql-escape-vector
                (apply #'vector (seq-map #'cdr destinations)))))))))

(defun vulpea-db-query-by-links-some-single (destinations)
  "Query a list of `vulpea-note' from database.

Only notes that link to at least one destination from the list of
DESTINATIONS are returned."
  (seq-mapcat
   #'vulpea-db--notes-from-row
   (org-roam-db-query
    (format
     "SELECT * FROM notes WHERE id IN (SELECT source FROM links WHERE links.type = '\"id\"' AND links.dest IN %s);"
     (emacsql-escape-vector
      (apply #'vector (seq-map #'cdr destinations)))))))

Benchmark result:

[00:20.629]  [vulpea-db-query-by-links-some-single] begin benchmark with 10 invocations
[00:22.870]  [vulpea-db-query-by-links-some-single] benchmark result is (2.2408159999999997 34 1.3603679999999994) after 10 invocations => 1767 notes
[00:22.870]  [vulpea-db-query-by-links-some] begin benchmark with 10 invocations
[00:26.362]  [vulpea-db-query-by-links-some] benchmark result is (3.492386 49 2.1438930000000003) after 10 invocations => 1767 notes
[00:26.362]  [vulpea-db-query] begin benchmark with 10 invocations
[00:36.941]  [vulpea-db-query] benchmark result is (10.578342000000001 65 5.856387000000002) after 10 invocations => 1767 notes

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 :)

Right now it's hard to guess the signature of FILTER-FN argument in vulpea-select function. Documentation says to checkout the documentation of private function which simply tells that "car is the displayed title for completion, and the cdr contains all the funny stuff". And only by checking the implementation you realise that it's actually a cons of a rendered/displated title (with tags) and a `vulpea-note'.

First, users should not go such a long path to understand how to use FILTER-FN. Secondly, I find it dauting to constantly apply cdr to get my vulpea-note' when I need to filter something. So it would be nice if FILTER-FNwould the note. Rendered title is pretty much useless and all information is available in a structured way inside of thevulpea-note'.

This isn't an issue, I'm trying to understand the benefits of vulpea that you describe. You use the phrase "consistent experience" a few places:
"vulpea-find that acts like org-roam-node-find, but (a) uses vulpea-select for consistent experience"
You use the same phrase "consistent experience" to describe how vulpea-select benefits vulpea-insert as well. How does the use of vulpea-select provide a more "consistent experience" in these cases?

Still very new to emacs so please bear with me.

Adding (package! vulpea) and running doom sync seems to run fine, but I can't find vulpea-setup in M-x to run after install. What am I missing here?

Hi!

I think that this is not necessarily vulpea's job directly, but it might be interesting to talk about it here, because vulpea has a solid base to do this kind of thing.

To describe my point in more detail, I noticed this: 

• a query-based system is much more efficient than a simple search system
• search and insert is in the end almost the same thing from the user's point of view (search for a certain note/node, then insert or go to that note/node)
• org-ql is incredibly powerful, but doesn't work for org-roam/vulpea (because most nodes are files.)

So my desire is to unify these three components: 
create a "super function" that would search for a note based on all possible parameters: 

• title (already done, build-in in vulpea)
• value of one or more metadata (already done)
• backlinks (already done)
• tag (already done too)
• etc

The interface would be close to org-ql. Maybe we should make queries like them, with predicates? I don't know, because it takes away from the simplicity, no? Anyway, that's another problem.

Then, after finding the right note(s), we could do actions on them: insert them, go to a note, others...

This will not happen overnight, but most functions can do without vulpea notes as an intermediary. (I'm not sure if this statement is correct in English)

As I said, vulpea may not be the best place, but this package has almost everything, it is almost enough to assemble the bricks already made (already, the fact that vulpea-find and vulpea-insert both use "vulpea-select" is a proof of this tendency to want to unify the search and insert system. It's genius to have done this).

The point is, I want your opinion! What do you think?

Personally, I think it's doable, it's almost revolutionary, but I'm afraid it's time for nothing in the sense that it's not an essential feature. Even if, currently, to insert a note, the way it works is: search for the title. If the title not enough, do a more thorough manual search (by ripgrep, org-ql, or another system of search), save the title in your memory, go back to the note where do you want to insert the link to the note, recall the insert function, enter the title, press enter.
This works perfectly, but in the end, it is a tinkering compared to a unification of the search and insert systems.

I'm not sure if this is related to Vulpea behavior, or my setup with Vulpea and Org-roam. But see the Discourse thread I opened in org-roam with the bug info and comments : https://org-roam.discourse.group/t/emacsql-sql-logic-error-no-such-table-notes-1-1/3520.

Original issue:
Recently my org-roam-db has been having a lot of issues with a lot of files. Here is a sample:
⛔ Error (org-roam): Failed to process /home/user/Dropbox/org/roam/daily/Personal 2021-09-10.org with error EmacSQL had an unhandled condition: nil, nil, nil, ("SQL logic error" "no such table: notes" 1 1), skipping...

There are hundred of entires it’s having issues with.
I have tried:
A resync.
A org-roam-db-clea-all into a resync.
Deleting the roam-db file at the org-roam-db-location and syncing again.

I'm very interested in being able to query my org-roam DB like with org-ql or logseq. I came across your package vulpea, but I didn't find any documentation on how to query the database, ideally beginner-friendly?

For example, I would like to do queries that return a list of all nodes that link to nodes A and B. Is something like this possible?

Right now by definition metadata can be placed only on the file-level. When #35 is implemented, we can support heading-level metadata.

vulpea does not detect my notes, even though org-roam works fine.

I use the following paths, which might be unusual, but I like having everything inside org-roam.

I have vulpea configure like this (using Doom):

(use-package! vulpea
  :hook ((org-roam-db-autosync-mode . vulpea-db-autosync-enable))
  :commands (vulpea-utils-collect-while))

What am I doing wrong?

Hello,

My question is in the title: would it be possible to implement the functionality of having a tag hierarchy in vulpea?

Concrete example:

If I have the following configuration (https://orgmode.org/manual/Tag-Hierarchy.html)

(setq org-tag-alist '((:startgrouptag)
                      ("GTD")
                      (:grouptags)
                      ("Control")
                      ("Persp")
                      (:endgrouptag)
                      (:startgrouptag)
                      (:Control")
                      (:grouptags)
                      ("Context")
                      (:Task")
                      (:endgrouptag))

That can conceptually be seen as a hierarchy of tags like this:

GTD
  Persp
    Vision
    Goal
    AOF
    Project
  Control
    Context
    Task

If one of the notes has for example the tag "Task" (in filetag), would it be possible that, when using the command "vulpea-db-query-by-tags-every", this note would be found if I ask for the tag "Control" or even "GTD"?

To conclude, I may not realize the difficulty of this feature :

Is it possible ?
Could there be alternatives ?
Is it complicated to implement ?

This feature would just be execeptional for me,

Thanks in advance for your futur answer.

Hello

I think I noticed a problem with the "vulpea-db-query" function.
My goal : make comparison options on numbers in metadata.

Let say the following note

:PROPERTIES:
:ID: 20220617115633324937
:END:
#+title: Test Page

- user :: email
- numbers :: 12

This query works

(vulpea-select-from "texet" (vulpea-db-query
                               (lambda (note)
                                 (and
                                  (string-equal (vulpea-meta-get note "user") "email")
                                  ;; (= (vulpea-note-level note) 0)
                                  (< (vulpea-note-meta-get note "numbers" 'number) 100)
                                  )
                                 )))

But this one, no:

(vulpea-select-from "text" (vulpea-db-query
                       (lambda (note)
                         (< (vulpea-note-meta-get note "numbers" 'number) 100))))

I don't understand why, and I think this is not normal.
The problem is that I have no idea where the problem could come from :/

Right now doing multiple reads in a row results in the following operations to be repeated:

• vulpea-db-get-by-id (calls to db)
• buffer parsing (using org-element API)

The most expensive here is buffer parsing. So it would nice if read operations would allow to pass metadata parsed from vulpea-meta, which in turn already allow to pass note or ID of the note.

Hi!

As said in the title, I would like to know how to manage this kind of note: it seems that everything works fine, the data is in the database... unfortunately, every time I interact the database, the password is asked. for each note. which is a lot and not practical. (I encrypted with the passphrase method).

Is there a way to not "interract" these notes except with a certain variable?
Should I use the "vulpea-find-default-filter" variable?

Thank you in advance for your answer

(PS : this may not be a Vulpea problem, but an org-roam problem).

After updating the latest version of persist meta in database, it seems to create an error:

EmacSQL had an unhandled condition: "no such table: meta"

when I use any vulpea functions such as vulpea-find. I have tried the vulpea-db-setup as well but still not fix this problem.

I tried to use the vulpea-based v1 to v2 migration script here but it looks like it might be out of date. When I run M-x vulpea-migrate-db, I get this error:

let: Symbol’s function definition is void: org-roam--list-all-files

See #96 for more context.

Basically, with org-roam-v2, properties are stored in the database, so we can easily expose them in vulpea-note, so you can find based on some property.

It would be nice to promote meta to first class citizen of vulpea-note, meaning that it needs to be persisted, it must be part of vulpea-note and the library should provide means to search/filter by meta.

This is primarily needed for performance of search and access, making meta more practical. Examples of usage:

1. You want to find all notes that have meta with 'producer' set to some note. Without this feature you have to open ALL notes, parse the file and filter. Opening file and parsing takes lots of time.
2. You wish to show some information about one or more notes. For example, title (already persisted) and some value from meta (not yet persisted). Without this feature you need to (again) open files and parse the data to present what you want.

Kind of follow up of #96 (reply in thread)

CC @hyan46

Since it's a very important part for vulpea to be functioning, it should be part of this repository and not as some recommendation.

it's not really a way out. I still have a little trouble with the pull request, so I'm doing it here.

I've modified "vulpea-insert" to have the choice to select the description (see in "description" variable in the first let). Is this a good idea?

(defun vulpea-insert (&optional filter-fn)
  "Select a note and insert a link to it.

Allows capturing new notes. After link is inserted,
`vulpea-insert-handle-functions' are called with the inserted
note as the only argument regardless involvement of capture
process.

FILTER-FN is the function to apply on the candidates, which takes
as its argument a `vulpea-note'. Unless specified,
`vulpea-insert-default-filter' is used."
  (interactive)
  (unwind-protect
      (atomic-change-group
        (let* (region-text
               beg end
               (_ (when (region-active-p)
                    (setq
                     beg (set-marker
                          (make-marker) (region-beginning))
                     end (set-marker
                          (make-marker) (region-end))
                     region-text
                     (org-link-display-format
                      (buffer-substring-no-properties
                       beg end)))))
               (note (vulpea-select
                      "Note"
                      :filter-fn
                      (or filter-fn
                          vulpea-insert-default-filter)
                      :initial-prompt region-text))
               (description (or region-text
                                (if-let ((aliases (vulpea-note-aliases note))
					 (title (vulpea-note-title
						 (vulpea-db-get-by-id
						  (vulpea-note-id note))))
					 (all-aliases (push title aliases)))
				    (completing-read "Insert: " all-aliases)
				  (vulpea-note-title note)))))
          (if (vulpea-note-id note)
              (progn
                (when region-text
                  (delete-region beg end)
                  (set-marker beg nil)
                  (set-marker end nil))
                (insert (org-link-make-string
                         (concat "id:" (vulpea-note-id note))
                         description))
                (run-hook-with-args
                 'vulpea-insert-handle-functions
                 note))
            (org-roam-capture-
             :node (org-roam-node-create
                    :title (vulpea-note-title note))
             :props
             (append
              (when (and beg end)
                (list :region (cons beg end)))
              (list
               :insert-at (point-marker)
               :link-description description
               :finalize #'vulpea-insert--capture-finalize))))))
    (deactivate-mark)))

Just to avoid the boilerplate of exchaning id to file and visiting it.

Hi! First off, thanks for your work on this project - I'm interested in using vulpea over the native org-roam interactive functions primarily for performance reasons, though the tag/metadata stuff looks like it'll be useful if I dig into it more.

I'm using org-roam-v2 on Doom Emacs, and I heavily use the "headings as nodes" feature of v2 rather than "one node per file" like in v1. One thing that's really useful is that when I use org-roam-node-find, the candidates will show all their parent headers, and in fact the search text will match all child nodes even if just the parent node title matches:

This makes it very easy to disambiguate nodes that have similar titles by looking at their parent titles, jump to specific child nodes under a given heading, etc. If I use vulpea-find, it only matches against the node titles themselves:

Is there some way to config Vulpea to get similar behavior from vulpea-find? Keep in mind I'm a relatively new Emacs user, so I apologize if this question is trivial or I missed some easy config option for this.

Thanks again!

This is a breaking change and should come as early as possible.

See more information in Emacs manual.

Took me a while to figure out why vulpea would not work.

Just to be aligned with aec0d18

Hello @d12frosted

I'm curious if there's a better way to do this, I suspect vulpea-db-query can do it but I can't quite wrap my head around it.

Every time I read a book, I insert a link to the year (2022 note) and the books note (books). I want to see all the book I've read in 2022.

This is what I came up with, is there a better way via vulpea-db-query?

  ;; get everything linking to 2022 note
  (setq twenty22 (vulpea-db-query-by-links-some
                 (list (cons "id" "6DB243A1-031D-4447-8C3F-70615A2237DB" ))))

  ;; get everything linking to books note
  (setq books (vulpea-db-query-by-links-some
               (list (cons "id" "D67FF1DE-AD9E-4DEB-846B-C36BF011D443"))))

  ;; extract the ones that link to both (intersection)
  (setq dm/vulpea-results (seq-intersection twenty22 books
                                            '(lambda (el1 el2)
                                               (equal (vulpea-note-id el1) (vulpea-note-id el2)))))

  ;; do stuff with it
  (seq-do (lambda (note)
            (goto-char (point-max))
            (insert (format "%s\n" (vulpea-note-title note))))
          dm/vulpea-results)

Context

I'd like to update a project status (defined as a description list item) in place using vulpea-buffer-meta-set, but when this is the only item in the description list, it adds a new line when updating (video below shows the issue). This does not happen when there are multiple items in the list.

Video

Will you support this going several years into the future?

So it works like vulpea-select, but instead of just showing the list of notes, it should list headings as the second step.

See org-ml project page for more information. In short, I think that it can simplify vulpea-meta code and make it possible to achieve #66.

I have hundreds of org-roam 'dailies' files with titles like 2021-11-15. By default, all such numeric entries are placed at the beginning of the completion list that vulpea-find provides. Removing such notes from the list would prevent searching them by tag. In order to see the normal titled notes when vulpea-find starts, it would be preferable for the numeric-titled notes to be at the end of the list, while the rest of the list is still sorted as usual.

Would it be possible to add a sorting function hook to enable custom sorting like this?

Hello,

Small context: 

I'm on ubuntu and would like to have emacs + org-roam + vulpea on my phone. Everything works fine (I use exactly the same configuration thanks to termux)

Except that, with exactly the same files, I have to redo the "(org-roam-db-sync 'force)" command in termux, which I don't understand.

The only files and folders that I don't copy from my pc's configuration are the following ones: 
straight/
var/savehist.el
var/save-place.el
var/recentf-save.el
var/keyfreq.el
which I think should have no influence (maybe straight)

So my question is: where is the "variable" / configuration that allows vulpea to read the "org-roam.db" file without doing the command (org-roam-db-sync 'force).

Thanks in advance for your answer ^^

The most obvious way to improve it is to mimic what was done for #64, e.g. allow to pass parsed meta to vulpea-meta-set, but it will not work when adding multiple calls with different props, as meta is modified between the calls, so vulpea-meta-set either should return a modified metadata OR approach this problem in a different fasion - by providing functions to modify meta and to write it.

Some context - #96.

In short, it would be nice to have interactive interface to modify metadata lists, e.g. vulpea-meta-add and vulpea-meta-remove. It should use note at point or read a note interactively. And should support list keys.