Updating wiki Link when changing filename
Completed
Hi,
I'am experimenting using wiki links. Love it!
But when changing a file name, all existing wikilinks are broken. Wouldn't it be great when renaming a file (via nvUltra) all existing wiki links are updated accordingly?
== feek
-
This has already been discussed:
Thank you,
Fletcher
0 -
Hi Fletcher,
your explanation makes it completely clear why it shouldn't be implemented :)
== feek
0 -
Hi Fletcher,
I have read why you feel this shouldn't be implemented.
In addition to nvUltra (which I love) I also use Obsidian for "my heavy lifting" of my personal Knowledge Management system.
Obsidian seems to do this perfectly well.
Understand if this is something that you don't want to do as I know (being a retired developer myself) that if you put in every request the software quickly becomes "bloat ware" and complex to use. Especially as I love the speed and simplicity of NvUltra.
On another note (pun intended :-) ) are we getting closer to the production version ?
I'm using it quite a lot now and have hit few (if any) bugs.
All the best to you and Brett in getting this to market!
0 -
1. I totally agree that every person is entitled to their own opinion. But I strongly believe that this approach to "WikiLinks" is wrong in the context of a folder of text files on disk that is not "owned" by nvUltra. As an analogy, if I move a page on my web site (e.g. `foo.html` -> `bar.html`), and add new content to `foo.html`, then I should not reach out and change every other web site on the internet that links to `foo.html` so that they now link to `bar.html`. The URL is `foo.html`, which is (in a technical sense) independent of the content located at `foo.html`. You link to the URL, not the content. Same thing with WikiLinks -- in this case the primary key is the WikiLink, not the file name. Other app developers are, of course, free to make different design choices.
2. In addition, I also strongly believe in not changing backing text files without being explicitly directed to do so by the user. Changing a filename in the Finder, for example, does not equate to the user explicitly telling nvUltra to modify the text in a separate text file (e.g., to convert `[[foo]]` to `[[bar]]`).As for a release date -- the app is essentially feature complete for 1.0. We are still fixing minor bugs that pop up. The main technical issue that stands between beta and production relates to the behind the scenes hoops we have to jump through due to Apple's slow but seemingly unstoppable migration from `WebView` to `WKWebView`. We are weighing the pros and cons of a change to the underlying back end of previews, and if we do this it *probably* should happen before 1.0. Additionally, I have a fair number of high priority responsibilities that have come up in my personal life that are limiting the chunks of time that would make a good window for releasing a 1.0 and the inevitable flurry of emails and possible bug reports that would follow. So this is more my "fault" than Brett's.
In the meantime, the beta is still being maintained and available for use!
0 -
Hi Fletcher,
Thanks for taking the time for the detailed reply.
Totally appreciate your arguments and can see the logic in them.
I can understand how hard it is for developers to keep up with Apple changes, especially with all the upcoming changes that will be triggered by the move to, Swift and Swift UI, "Apple Silicon" :-), etc.
I've also greatly inhibited my free time by recently taking in a Mature Age University (UTAS) degree in ICT so can appreciate you needing to carefully plan out your time.
I'm happily using the Beta so no problems on how long it takes to go to Production. Getting it right and being able to provide quality support to paying users is important.
As my partner always says "Remember to breathe" lol... All the best!
0 -
👍
0
Please sign in to leave a comment.
Comments
6 comments