Zettelkasten Forum


Atom (editor)

I've been using Atom for years to keep hundreds of personal notes in markdown format. Then I learned the Zettelkasten method from How to Take Smart Notes (mind BLOWN!). But there was no good way to link notes together in Atom.

So I created linkist and have begin to use it. It creates short document links that survive no matter how you rearrange the files in a project.

If you're an Atom user, give it a try and let me know how it goes!

Comments

  • Very cool, thanks for sharing! I never picked up Atom except for its technical novelty back in the day, but we inherited a couple of packages from Nick that might be interesting for you (or other Atom users)

    • https://github.com/Zettelkasten-Method/atom-wikilink -- [[wikilink]] support, originally by Dan Sheffler, but not maintained since 2015, this fork makes links clickable relative to the current project, includes keyboard navigation, and such things. (I don't remember the exact details to be honest :grimace: )

    • https://github.com/Zettelkasten-Method/atom-plumber -- an unconventional package that relies on a text-based inter-process communication protocol called "plumber", which is super interesting, but also a very fringe topic :)

    Author at Zettelkasten.de • https://christiantietze.de/

  • Thanks! I had looked at wikilink but renaming is a problem. I wanted a permanent tag for links so that I'm totally free to rename and manipulate all human-readable text without breaking any links. Seems more in the Luhmann spirit.

  • @Glade, your Atom package is how I discovered Zettelkasten--from your little note at the bottom of the package's page.

    I had been browsing through wiki-ish Atom packages for a simple way to get out of proprietary apps that now contain all my (mostly unlinked) notes.

    The simplicity of linkist is very attractive, but it puzzles me that there is no "target," only a sort of ring of related notes that have the same tag. In fact, how is it different than using tags... that are auto-generated by timestamp except not actually readable as timestamps? ;) I did see your comment elsewhere that you prefer the time to be unreadable, to allow you to read the note in a fresh, time-free context, so I do understand that part.

    Am I wrong about the lack of a "target" note? Can you explain why you prefer it?

    Thank you.

  • It's a whole world. Glad you found it!

    I follow a convention that seems to work so far.

    topicOne.md:

    # [topic one](^abcd^)
    
    Stuff about topic number one....
    

    topicTwo.md:

    # [Topic two](^wxyz^)
    
    Stuff about topic two...
    
    * [As related to topic one](^abcd^)
    

    I'm still working on ways to incorporate date operations and info. Dates are useful!

  • So you press the hotkey and toggle back & forth between the two notes. That clearly works well in this case, but I was wondering about many-to-one mappings, where several not-very-related notes link to a smaller core of general concept notes. Wouldn't you want the hotkey to take you to the intended target note, one of the core at the center of the wheel, instead of the other lukewarm or cold connections around the wheel?

  • Yes. There is code that prioritizes the first link that starts with #. So if you hit the link it should take you headings first. Let me know or raise an issue if it's not working!

  • I see!
    So the context of having the link inside the main # title makes it a target? And then if you keep hitting the key, you start to see the others that link to it.
    That is a very clever way to keep it super minimal and elegant.
    Thanks for explaining that!

  • There are other operations I want to add. Feature creep I know but imagine:

    • Show me some things that aren't linked very well (dangling, unlinked, few links)
    • Show me links made during a specific time period
    • If I'm typing a link like [topic... suggest some fuzzy matches based on text found in other links

    I can already do these with external scripts but would like to add if it can be done non-invasively.

  • edited May 26

    External scripts rule!
    I just wrote about using them to serve multiple editors efficiently:
    https://forum.zettelkasten.de/discussion/comment/6339/#Comment_6339

    Take the logic out of editor-specific scripts, and let any editor call a central app/script/handler/thing that converts a zettel ID into the desired file name or other info (backlink file list...).

    (not that I'm doing any actual work here, just tossing out ideas) ;)

Sign In or Register to comment.