Wiki style links

[ghost]

Do you plan to wiki style interlinking between notes? This would support direct jumping between notes without loading the title into the search box. I think Nvalt has this feature. My apologies, I am not at a point with Coffeescript to where I could submit a pull request. Thanks!

[jonmagic]

Definitely one of my favorite features of NValt. Not sure how difficult it will be to implement in an Atom package but could definitely be a fun project to explore.

[ghost]

I found similar functionality in awiki perhaps a similar implementation could be made in nvatom.

There are also several packages on atom.io which use the fuzzy finder to match local files from the string under the cursor.

So perhaps an implementation would be to grab text between bounding brackets [[ ]] and use some type of query to load a direct file match of that text, or create new file if no text match.

I think this is the action of the search box, so perhaps it's just a directive to bypass the search box when there are bounding brackets, thereby using the current query method... but triggering that method directly from a keybind, using the current string.

[seongjaelee]

Started working on it. https://github.com/seongjaelee/nvatom/tree/feature-34

I think the basic features you described are there.

One thing I had to decide is to whether to use absolute interlink or relative interlink, and I decided to use the former. For example, Car/Hyundai.md containing [[Blue]] will lead to Blue.md, not Car/Blue.md. The latter would be harder to counter-reference all interlinks when moving/renaming a file. If you think this policy should be changed, let me know.

I need to

1. play it by myself as a dogfooder, and
2. add documentations and probably unit tests,
   to merge the branch into the main branch, but you can also dogfood it if you want to try.

[ghost]

Wow, You're fast! 🏃💨 Many thanks.

So to make sure I understand how it's built, given a notes directory of:

notes/Blue.md
notes/Car/
notes/Car/Hyundai.md:[[Blue]]
notes/Car/Blue.md

The link of [[Blue]] points upwards into notes directory to link to notes/Blue.md?

After giving it some thought, I think your decision makes sense. It assumes the most common usage is for the majority of notes to exist within the root notes directory, with some sub-folders used on occasion. I think this assumption is correct. Given that most users default to the root folder, interlinks should do so as well, and if the user wants to reference a relative file, then input the full path like so:

notes/Car/Hyundai.md:[[Car/Blue]] links to file notes/Car/Blue.md

Am I correct in my understanding?

Also, I tried to update to feature-34 but it keeps throwing this error.

[seongjaelee]

@xhn35rq Yes you are right. I think nvalt does not have directory structure, it automatically uses absolute (to the note directory) interlink.

Thanks for trying it out already. =) I'll fix the bug soon.

[seongjaelee]

I think I fixed the bug. Thanks for the testing again! 👍

[ghost]

I think nvalt does not have directory structure, it automatically uses absolute (to the note directory) interlink.

Correct. Thanks for fixing the bug I'll start dog-fooding on Feature 34.

[ghost]

The linking works fine so far, however:

• Syntax coloring does not always work, perhaps because the filetype is now nvatom markdown and switching to Github Markdown disables the linking. Sometimes I'm required to reload the view several times before syntax coloring works.
• If I rename a file, the links are not updated in other notes. I don't think you added this functionality, however it would be nice to have. I'm not sure how difficult it would be.
• Following a link breaks file renaming and re-introduces this bug: File rename issue atom/atom#3113 Restarting Atom fixes the file renaming, however renaming breaks again after following a link.

[ghost]

Just had a thought: the switch to search-index (#35) would potentially allow for re-writing of links throughout all notes upon renaming a single note.

[seongjaelee]

I think I fixed this syntax coloring problem. It only applies this interlink open/highlight feature under the note directory.

Auto-updating other links - I didn't implement it. nvalt also does not do that. It would be nice to have, but I think it is beyond my skill yet. I'll create another issue for this.

For the case sensitivity, this is an interesting bug. I'll follow the precedence of nvalt.

1. If we have Car.md and [[car]], then opening the interlink should open Car.md, not car.md.
2. If we have car.md and [[CAR]], then opening the interlink should open car.md, not CAR.md.
   But this behavior is problematic if pre-existing notes have CAR.md and car.md. I guess no OSes allow that "CAR.md" and "car.md" can coexist within a same directory?

[ghost]

I think I fixed this syntax coloring problem. It only applies this interlink open/highlight feature under the note directory.

Thanks, I'll test it out! 👍

Re: case insensitivity just to clarify the bug that I found: after following a link, renaming a file from within Atom doesn't rename but instead duplicates the file you're trying to rename. The old file retains the current name, while the new file is given the name you enter into the "Rename" field. This bug was supposed to be fixed but is re-triggered after following an nvatom link. Restarting Atom eliminates this bug, and renaming works as normal, until you follow another nvatom link.

Sorry if that was duplicate information, I just wanted to make sure I had clearly outlined the bug.

I guess no OSes allow that "CAR.md" and "car.md" can coexist within a same directory?

I can create both CAR.md and car.md within same directory on Ubuntu and I think most Unix-like OS allow this.

[seongjaelee]

Oh... then we have two options.

1. If we have Car.md and [[car]], then opening the interlink should create car.md
2. If we have Car.md and [[car]], then opening the interlink should open Car.md

Choosing 1: I think people would prefer using case insensitive format. nvalt also does this. For example, it is common to mix cases in wiki, as if these keywords are used in a normal sentence. For example,

[[Notational velocity]] is a blah blah blah. ... However, [[notational velocity]] does blah blah.

Choosing 2: If we have CAR.md and car.md, then [[car]] should direct car.md. [[Car]] can go either car.md or CAR.md. If the directory is empty, then [[Car]] should create Car.md. If someone wants to keep CAR and car intentionally... it will be somewhat confusing.

I think 2 is more intuitive to users. What is your thought?

[ghost]

I think case insensitivity makes sense, so 1 is more intuitive to me. If I want to define between notes, I give notes different names, rather than giving them the same name with different cases. Trying to differentiate between notes with cases doesn't make sense to me.

I'm curious why you think 2 is more intuitive.

[seongjaelee]

Case insensitivity is option 2, not 1. The reason I chose 2 is,

1. most people does not care about case sensitive (case-insensitive-dup) filenames (e.g., creating CAR, Car and car separately).
2. nvalt does that.
3. the origin of interlink is from wikilink, which is case insensitive.

[ghost]

Ah ok, I see what you mean. What I meant to say is "do whatever nvalt does" 😄 I thought that's what you meant by 1.

Also, I had another thought about search-index: would it make sense to trigger a query of the index DB upon clicking a link, instead of jumping directly to the note file? Both note titles (first line of markdown doc) and note file-names can be searched for. Jump immediately to note if there is a single result, however if multiple results, then return the results in a Popup, and let user select note to jump to. And if no results, create new note. This way, the user can find duplicate notes, or notes that might have been name improperly, and would aid in pruning and cleaning the notes DB.

[seongjaelee]

"The duplicate notes" is only for the case we have multiple case insensitive files (e.g., Car.md and car.md). I think introducing this behavior for such exceptional cases is an overkill.

---

• Trigger a query of the index DB upon clicking a link, instead of jumping directly to the note file
• Jump immediately to note if there is a single result, however if multiple results, then return the results in a Popup, and let user select note to jump to.

I came with some edge cases on this behavior:

1. Let's say we have two files: World.md and Worldmap.md.
   Then, if we click [[world]], it will pop up the note selection window asking whether to move World.md or Worldmap.md. nvALT won't have such a problem, since note selection window is not a popup. But in our case, we should focus the cursor to the note selection window, and then the user have to press enter to select a note (probably World.md).
2. Let's say we have one file: Worldmap.md.
   Then, if we click [[world]], it will directly move to Worldmap.md. I think this is counter-intuitive.

---

A modified behavior I can think of is, just do the lowercase exact title matching on existing files. If we have multiple of them, then pop up a selection window. In this case, if we have Worldmap.md, World.md, world.md, then [[WORLD]] will pop up a note selection window with World.md and world.md, and [[WorldMap]] will open Worldmap.md.

However... I think this is still an expensive feature for an overly exceptional case.

---

Both note titles (first line of markdown doc) and note file-names can be searched for.

I think assuming the first line of markdown doc to be a title might be too bold. Some people might use multimarkdown format with headers something like,

Author: Fletcher T. Penney  
        John Doe  
Date:   July 25, 2005  
# Title of the document

For my case, I sometimes omit adding title on the first line.

[ghost]

All good points, thanks!

Also, I just realized that @jonmagic mentioned using a file-watcher such as chokidar to monitor the note root directory, so the search-index database will be always kept up-to-date. So I cannot for the moment think of any good reason to query against the database when following a link.

[jonmagic]

Great discussion here. I like the conclusion, start simple 👍 Down the road if we hit edge cases that affect a lot of people we can iterate.

[ghost]

I did think of a situation where querying the database would be helpful when following a note-link.

I've become aware that some people create a specific ID for each note, for example 82f5950c and put that ID into the note file name. Then they create a note-link using this ID, for example [[82f5950c]] and use fuzzy-matching as the method to follow the link whichever note file contains this ID. This allows them to easily change the titles and file-names of each note without breaking any links, as long as the ID remains somewhere in the file-name.

But this does feel like an edge case as I'm not sure how many people use this method to link notes.

As an aside, this method does offer an alternative way of keeping links up-to-date between notes, without needing to manually or automatically re-write all links in every note.

[ghost]

Wiki style links added in v0.9.1 release - thank you @seongjaelee 🏆 😄

[seongjaelee]

Thanks for suggesting the feature and following up this issue! =)

(I forgot to answer your last comment... I thought it was an interesting idea for those who names the file with that rule, but I didn't want to force such a rule to the users. And, as long as the feature is not supported from nvalt, I would put its priority low.)

[ghost]

I didn't want to force such a rule to the users.

I think that is a smart decision. Thanks for the followup