Is there a mechanism to easily identify broken links in V2?

I have to get back to it when I am less in a hurry then to understand it well before jumping head first.

For case 4 maybe the https links were not affected, as I said I rushed for undo when the whole buffer got modified with the test title popping up everywhere. I am sure the test links did not budge though because I was staring at them when hitting Enter.

I will get back to it tomorrow morning and report back, thanks. :+1:

1 Like

Do you know how to run edebug ? when you do the test - run e debug – youd get step by step what is happening – press

C-u C-M-x    on the function in question

when you then run the function – it would take you step by step through it – press <space> to go forward

also all these foo bar is making my head spin – can you do the same experiment on the files in question – make sure to make a backup or run it on the backup – make a video if possible or screenshots, anything would help.

Do tests in your free time, no worries - I don’t know what caused it, but it seems impossible how such a execution point may be reached logically.

Also by currently I mean the value that is going to be replaced – what should be a good term for it? It is not the default value but the value we’d compare against to see which ones are generic descriptions and which ones are custom descriptions.

I think currently is fine in that case, I just did not take time to think. I got used in Emacs that some functions add a default value in brackets after the prompt based on the value at point for example. So I just hit Enter. Now that I understand better the new logic it does not make much sense to have a default value in a rename function.

Thanks for the tip, it is a very useful functionality.

Sorry about that, I will try to add some screenshots tomorrow when trying it again.

1 Like

I made some more modifications in an attempt to never do any collateral damage.

Scope limitation (prevent collateral damage)

-  (when (or (string-match-p (concat "id:" idd) (match-string 0))
-            (string-match-p title (match-string 0)))

is replaced by

+ (when (or (string-match-p (concat "^id:" idd "$") (match-string 1))
+           (string-match-p (concat "^roam:" title "$") (match-string 1)))

we do not compare against the entire link, we also make the test more strict.
This will doubly make sure we never ever process any links that don’t exact match description.

Do not process illegal request.

(when (string= "" new-title)
	(user-error "Warning! You have decided to delete current node-title and propagate changes.
Aborting! This is not allowed."))

Added logic to discard the case when user enters blank input for rename

Enhanced function cohesion

Tolerate all possible choices that form out of several combinations of situations.

  • Deal with [[id:uuid]] cases as well in addition to [[id:uuid][description]]
  • Deal with the case that a rename has been requested when some links are of roam: type

Misc.

I also advice setting

(setq org-roam-link-auto-replace nil)

This will turn off org-roam’s auto replacement strategy – which affects all roam: links – they will be replaced immediately on save (or write-file). I have devised the functions such that this auto replacement is redundant, you can keep it turned on if youd like - but for the test try turning it off - this way we can seperate the effect of my functions from roam’s replacement strategy.

This is an interesting read. Have you used the fact that tags can be inherited?

I think this is what we try to do with tags and inheritance and adhering to some naming conventions. For example, say I use the tag β€œneverseenproject” to mark a given project, and only for that. Then I can gather any knowledge that relates to this project. And then I can add to the node find template org-roam-node-display-template β€œ${tags}”, and I will be able to narrow my search to nodes that relate to this project. Nodes will still not have a clear tree structure (more like a bunch of sibling nodes under the same parent). I guess you can have multiple inheritable tags: one for the top level, one for the chapter, and perhaps one for the section. As long as you keep your names consistent, you should be able to keep track of the info you want.

The database provides also a clean interface (using babel) that will allow you to enumerate all nodes that have a given tag (included inherited tags).

* My container :neverseenproject:

this is a node in this file

** this is another header
:PROPERTIES:
:ID:       id-20240605-141650
:END:


** second header under it
:PROPERTIES:
:ID:       id-20240605-141728
:END:


Here is a way to list the files that have a given tag. This code can be easily converted to a function that inserts the results as a list of bullets or a table as a link.

#+begin_src emacs-lisp   :exports both :var tag="neverseenproject"
(org-roam-db-query [:select [node_id title nodes:file nodes:pos]
                    :from tags
                    :join nodes
                    :on (= tags:node_id nodes:id)
                    :where (= tag $s1)
                    :order-by title
                    ]
                           tag))
#+end_src

#+RESULTS:
| id-20240605-141728 | second header under it | /Users/dmg/tmDropbox/org/roam/daily/2024-06-05.org | 2316 |
| id-20240605-141650 | this is another header | /Users/dmg/tmDropbox/org/roam/daily/2024-06-05.org | 2239 |

@dmg @lyndhurst

We should clean up our chatter – an user coming here will be lost in this, there is a limit in how much can be deleted in one day – but I have began deleting all my redundant messages.

I hope we can agree to keep this chat as a welcoming place for new users happening upon.
We can always discuss more things in different places. Consider just keeping the original question and the final solution –

Please post any more problems in the github gist itself.

I did not realize I was digressing that much. I will keep it more to the point in the future, sorry about that.

I have tested your last revision of the repair function, and commented on github.
With screenshots this time :slight_smile:

Thank you for the tip, I am aware of tag inheritance, but tagging is one of the most complicated and discussed aspect of note taking.There are multiple articles on this website with many interesting insight on the subject, but as akashp reminded us, this is not the topic of this thread, so another one should be open to discuss it further.

This is the last off topic item I am gonna add because I think it can be useful to less tech savvy users who had the courage to soldier through this thread. I use this kind of strategy for simple use cases like in your example with dynamic blocks thanks to the (imo) very user friendly package org-roam-ql. But this does not constitute a structure note per say, and while relevant to note taking it is rather of out of the Zettelkasten scope imho. But this again is worthy of a separate thread.

@akashp last digression I swear !

I think I understand fundamentally the problem –

we cannot have the rename and the repair function together - I wanted to make some efficiency gains and wanted to process a buffer at the same time rather than do each link one by one - this is causing us problems,

Fundamentally I think your original question is answered - that is how to find them, the find function works alright –

I need to rewrite the rename functionality and break it away from the repair functionality - that will solve all our issues,

I have deleted all my earlier messages - I wish we had some admin to whom we could appeal to restore some messages, only the message related to the find functionality – since that is the only one that is relevant to this thread.

Admin please help.