לדלג לתוכן

Markdown Standards

אין לי כוח לתעד אבל עשיתי סדר בהוטקיז אלט W - להכניס כל טמפלט אלט E - לדחוף לקובץ אלט D - להמיר אמבד קונטרול אלט E - להעתיק לקובץ קונטרול אלד D - להכין קובץ להעתקה (אליאס עם הבלוק רפרנס) קונטרול אלט O - לפתוח את הקובץ דאמפ (מגדירים את זה בהגדרות...) קונטרול אלט P - טוגל לסייד פיינים וקוויק סלקשן (קונטרול אלט אנטר כדי לפתוח נואוט בספליט)

משהו גרם לקו של השורה הנוכחית באדיטור להיות קצת ירקרק וזה מעולה. משאיר את זה ככה. אפשר לראות את זה בתוך ציטוטים...

אין ספק שאני מעדיף להשתמש בהערות כלליות בגוף הטקסט מאשר באנקורים. אני גם ככה לא יודע מה יהיה 'חזק' ו-'חלש' בניתוח שלי את ההוגה בעוד כמה שנים, אז זה יותר משהו זמני. דאמפ ציטוטים יכול להפוך בהמשך לקובץ ציטוטים עצמאי, ותמיד אפשר למצוא את הציטוטים על ידי חיפוש של [...].

החזרתי את הצבע לבלוק רפרנסים כדי שאצליח לא לזיין אותם... הם חייבים להיות בסוף של בלוק. לגבי אנקורים אחרים... אני צריך או להוסיף אותם בילט-אין ל-ALT-E או להפסיק להשתמש בהם...

קצת צולע, אבל ייסדתי את alt shift d כדי לצרף לבחירה קישור לבלוקווט שלה, וסימן של ציטוט ואת alt shift e כדי לדחוף את זה ישירות לקובץ המטרה היא שבמקרה שיש לי bullet מאוד ארוך שלא מתפצל כמו שצריך - אוכל להעביר לקובץ דאמפ כמה שורות בלי לאמבד את כל הבולט. התהליך הוא לעשות alt shift d, לסדר קצת את השורות (כי הבלוק רפרנס עצמו גולש 2 שורות מטה) ואז לעשות alt shift e כדי לדחוף. זה מקרה שימוש נדיר יחסית אז הכל טוב. כמו כן, ctrl shift a פותח עכשיו את ה-yaml properties כדי שיהיה לנו select all וכדי שיתאים לקיצורים של פתיחת side panes אחרים. כמו כן, חשוב לזכור שבדאמפ פייל שלנו הסדר יהיה prepension - כלומר שנוסיף את הפריט החדש ביותר דווקא להתחלה (ואז, משום מה, תמיד תיווצר לנו שורה חדשה פנויה...) בגדול אני מעדיף לעבוד עם אמבדים כל כל אחד הוא שורה אחת.

ה-block quotes נראים טוב!!!

צריך להמיר את כל האמבדים לטקסטים עצמם רק בסוף - אחרת קשה למצוא את השורה הנכונה בקובץ הדאמפ

אוקיי - שמתי את ליינברייק על ALT1 ואת התו הבלתי נראה על ALT2 בגדול כל הכתיבה שלי כרגע עושה render אחלה ממש מעניין לשים לב שהבעיה של אינדנטציה בשורה מתחת ל-number list לא קיימת ברינדור מעניין אם זה ככה גם לבולטים או ששיניתי את שניהם. \ איזה קטע - זה ככה בלי קשר לסניפט שלי. אז כל הבעיות ביישור של הטקסט הן רק ב-preview. בכל מקרה - הכתיבה הנוכחית שלי אמורה להתרנדר די טוב. חשוב רק לשים לב שאני שם
בכל מקום שאני רוצה בו שורה ריקה, ושאני שם תו בלתי נראה (ALT2) בכל מצב שאני שובר שורה בתוך בולט - (בכל מצב שבו השארתי שורה ריקה ב-preview) - אחרת, כשזה עושה רנדר זה פותח פסקה חדשה שלא נמצאת באותו 'גובה' עם הבולט.

בשביל לקחת כותרת כבלוק - להכניס את האנקור מתחת לכותרת (כדי שלא ישנה את הכותרת...) בשביל לקחת בלוק כבלוק - לשים את האנקור בסוף הבלוק

לפעמים כשאני כותב אני רוצה 'לתייג' חלק מסוים בטקסט. כלומר לקשר אותו לאיזשהו תג רחב יותר שאני יכול לדפדף בו בבוא הזמן. נגיד - לסמן כל ציטוט של שפינוזה. אפשרות אחת היא להשתמש בקישור - נגיד ליצור דף בשם 'ציטוטים', ואחרי כל ציטוט לשים קישור לדף. ככה יתקבל דף שאפשר לראות בקישורים שלו את כל האזכורים הרלוונטיים. זה נחמד. אפשר להשתמש גם במילת מפתח. ככה, אפשר ליצור query עבורה, וגם להשתמש בו כקישור או לשמור אותו במועדפים. החיסרון בשתי השיטות הוא שזה מורכב... זה לשים מילה ייחודית או קישור בכל פאקינג מקום. על פניו, ליצור קישורים זה סבבה. אפשר אחרי זה ליצור פתק בשם של הקישור, לא חייב שיהיה אחד מראש. אם נלחץ עליו לפני שיצרנו הוא פשוט יצור את הפתק. לכתוב מילת קוד יהיה קצת מוזר. אני יכול לנסות להכין סניפט של HTML של קישור קטן כדי שירוץ גם בלייב וולט. אני לפחות צריך אוטומציה של ליצור את הקישורים המזדיינים האלה. ככה שאני רק אצטרך ללחוץ על קיצור כלשהו ואז לבחור להם שם. אני מניח שהייתי שמח ליצור פילוח של קטעים שארצה לקרוא אח"כ כדי לחשוב עליהם, של ציטוטים, של רפרנסים מעניינים על ההיסטוריה של הפילוסופיה, דברים שאני רוצה לקרוא ועוד. הכל טוב. ניצור איזושהי מערכת סימון. ואז נפריד את הפתקים שאני רושם לפתקים 'ישנים', פתקים חדשים ופתקים פעילים. פעילים כוללים גם פתקים זוכרים שיש להם תפקיד אקטיבי, אפילו אם נדיר. את הפתקים הישנים נחזיק לוקאלית על כל מכשיר. את הפתקים החדשים נכתוב באיזשהו אופן שקל לסנכרן, ונשמור מעט מאוד מהם - נעביר אותם כל הזמן לישנים. את הפתקים הפעילים או שנשמור כמו את החדשים, או שפשוט נשמור בקיפ... המטרה היא שאוכל לכתוב פתקי הגות באופן שמקושר עם סיכומים שלי. ^חזק ^6ahmkv

Edit history

יש לנו גם file recovery של אובסידיאין וגם את התוסף edit history לשים לב שהתוסף יוצר לכל קובץ ב-vault קובץ edtz מתאים יש לי css שמעלים אותם אבל צריך לראות אם זה מעצבן מדי... אפשר גם להגיד ל-file recovery לשמור סנאפשוט כל חצי דקה. // האמת שמחקתי את התוסף... פשוט הגדרתי שיהיה סנאפשוט כל 30 שניות. האופן שבו הוא עובד הוא כזה: הוא עושה סנאפשוט רק אם הייתה עריכה בקובץ. והוא מכליל את כל העריכות שקרו באותו חלון זמן של 30 שניות כחלק מאותה עריכה (עושה סנאפשוט כשיש עריכה, גג פעם ב-30 שניות).

Meta Vaults

If you create relative links inside the meta-vault, but within the folders that belong to the original vault, they should indeed be identical to relative links created in the initial vault. This is because relative links are based on the file's location relative to other files, regardless of the vault structure above it.Here's why this works:

  1. Relative links are based on the file's position in the folder structure, not the vault structure1.
  2. The meta-vault doesn't change the underlying folder hierarchy of your files1.
  3. Obsidian treats links within the same folder structure consistently, regardless of whether they're in a sub-vault or a meta-vault5.

This consistency in relative linking is one of the advantages of using relative paths in Obsidian. It allows for portability and flexibility in your note organization, even when working with complex vault structures3.However, it's important to note that while the relative links will work identically within Obsidian, you should ensure that your "Files & Links" settings in Obsidian are set to use relative paths for maximum compatibility2. This setting will ensure that new links are created in a format that's consistent with your existing structure and portable across different systems or vault configurations.

Share

Rewrite

CommonMark Cheat Sheet

לינק אבסולוטי: חומרה - ה-vault היא ה-root, הכל חייב להתקיים במבנה של ה-vault השלמה לינק רלטיבי: חומרה - ה-file structure מתחיל מאיפה שהקובץ, ורק subfolders נכנסות ל-path. - הופך את כל התת-תיקיה שהקובץ יושב בה לעצמאית מבחינת לינקים - זה הסטנדרט ב-Markdown וכל התוכנות מצפות לזה!

TLDR: 1. אנחנו שומרים את כל הלינקים ב-Relative Paths, ומשתמשים ב-Standard Markdown Syntax -- כדי שנוכל לעבור תוכנה. הכל מוגדר באמצעות התוכנה, רק לשים לב שזה עובד. 2. אנחנו משתמשים בכמות מינימלית ביותר של Header Links, ומדי פעם עושים בדיקה ללינקים שבורים (יש תוסף לזה)

Standard Markdown

אובסידיאן משתמש במה שנקרא Wiki Links - זה אומר שהוא מקשר ככה [filename] ועושה ריזולב לפי שם הקובץ - בהתעלם מתיקיות (לכן לא צריך פאת' כל עוד הקובץ ב-vault). כדי שנוכל להגר לאן שנרצה, אנחנו צריכים לינקים שגרתיים יותר של מארקדאון. אז במקום, נעשה (relative-path-to-file)[text]. הכל מוגדר אוטומטית דרך התוכנה, רק לוודא שזה עובד.

Relative Paths

אנחנו שומרים את כל הלינקים ב-Relative Paths! הסבר:

Yes, Obsidian uses wiki-style links by default, referencing files by their name rather than their full path. This allows for easy renaming and moving of files without breaking links.

  1. [[Note Name]] → Links to a note with that exact name in your vault.
  2. [[Folder/Note Name]] → Links to a note inside a subfolder.
  3. [[Note Name#Heading]] → Links to a specific heading inside a note.
  4. [[Note Name^BlockID]] → Links to a specific block inside a note.

Why No Absolute Paths?

  • Vault-wide linking: Notes can be moved without breaking links.
  • Cleaner URLs: No long paths cluttering your markdown files.
  • Better cross-platform support: Works the same across devices.

How to Force a Full Path?

If you need absolute paths, you can:

  • Use Markdown links instead:

    [My Note](file:///absolute/path/to/note.md)

  • Use obsidian://open?path= links (if supported by your setup).

Let me know if you need a workaround! 🚀

Difference Between "Relative Path to File" and "Absolute Path in Vault" in Obsidian

1. Relative Path to File

✅ Example: [Link Text](subfolder/filename.md)
✅ Best for compatibility with other Markdown tools

  • Saves links with folder structure included.
  • Works even if the linked file is moved within the same folder structure.
  • Compatible with most Markdown editors, static site generators (Hugo, Jekyll), and Pandoc.
  • If you move the entire vault to another location, links remain valid as long as the relative structure is unchanged.

2. Absolute Path in Vault

✅ Example: [Link Text](/subfolder/filename.md)
🚨 Only works inside Obsidian, not standard Markdown

  • Starts with /, treating your vault as the "root" (/ = Vault folder).
  • This format is not recognized by most Markdown tools outside Obsidian.
  • If you move your vault to a new location, Obsidian can still find files, but other editors won't.

Can You Use Absolute Paths?

❌ Absolute paths (/subfolder/filename.md) are not portable outside Obsidian.
❌ Most Markdown parsers will not understand Obsidian’s absolute vault path format.

Which One Should You Use?

🔹 If you plan to keep using Obsidian → Either option works.
🔹 If you want maximum compatibility with other tools → Use Relative Path to File (subfolder/filename.md).
🔹 If your vault is large and well-structured → Relative paths help keep things organized when moving files around.

Would you like a way to batch-convert links in your vault to relative paths? 🚀

חידוד חשוב על מבנה תיקיות ב-Relative Path

What happens when a relative link has to move back one directory in the folder structure? Say I have folder A, inside of it some notes and folder B. Inside folder B there are additional notes. With relative links, a note in folder B that links to a note in folder A would be formatted as "Folder A/Note.md", but how does any program know where folder A is? It's not within folder B, and it's not an absolute path.

ChatGPT said:

Good question! The way a program (like Obsidian or a Markdown parser) resolves relative links depends on the working directory (root location) of the vault or project.

A relative path assumes a starting point (usually the location of the file that contains the link) and navigates from there.

Example File Structure

/Vault ├── NoteA.md ├── FolderA/ │ ├── NoteB.md │ ├── FolderB/ │ │ ├── NoteC.md

Linking From NoteC.md (inside FolderB) to NoteB.md (inside FolderA)

  1. Using a Relative Path (moving up one directory):

    [Link to NoteB](../NoteB.md)

    • .. means "go up one directory" (from FolderB to FolderA)
    • Then, it looks for NoteB.md
    • Using an Absolute Path (relative to the vault root, works in Obsidian):

    [Link to NoteB](FolderA/NoteB.md)

    • This works because Obsidian treats the vault as the root directory.
    • It doesn’t matter where the file is—it will always find FolderA/NoteB.md.

How Does a Program Find FolderA?

  1. Obsidian (and similar apps like Logseq, Foam) treat the vault as a self-contained root.

    • FolderA/NoteB.md is understood as being inside the vault.
    • Even if you move FolderA around inside the vault, Obsidian updates the internal reference.

    • Markdown Parsers (like Pandoc, MkDocs) depend on the working directory.

    • If you're in FolderB, ../NoteB.md works because .. moves up one level.

    • If the parser starts in the vault root, it needs FolderA/NoteB.md.

What Happens If You Move FolderB?

  • Relative links (../NoteB.md) will break unless updated.
  • Vault-based links (FolderA/NoteB.md) will still work in apps like Obsidian.

Would you like help with a script to convert relative Markdown links to vault-based links for better portability? 😊

obsidian does ../FolderA/NoteB.md (going with your example). Is this a proper RELATIVE path?

ChatGPT said:

Yes, ../FolderA/NoteB.md is a proper relative path, but whether it works depends on what the "current directory" is when resolving it.

Breaking it Down:

  • ../ moves up one directory from the current file's location.
  • Then it looks for FolderA/NoteB.md.

Example File Structure

/Vault ├── NoteA.md ├── FolderA/ │ ├── NoteB.md │ ├── FolderB/ │ │ ├── NoteC.md <-- This file contains the link

[Go to NoteB](../FolderA/NoteB.md)

  • ../ moves up from FolderB to FolderA.
  • FolderA/NoteB.md is then found.

Is This a Standard Markdown Relative Path?

Yes! This is standard for file system-based relative linking, and it works in: ✅ Obsidian
✅ Markdown previewers that follow file system paths
✅ MkDocs, Pandoc, GitHub wikis (if used correctly)
❌ Some web-based Markdown renderers (because they lack a directory structure concept)

Why Doesn't Everyone Use This?

Many apps, including Obsidian, default to "vault-based paths" instead of strict relative paths.

  • This is why FolderA/NoteB.md works in Obsidian, even if you move files around.
  • But in plain Markdown, FolderA/NoteB.md only works if the parser treats the vault root as the base directory.

Would you like a script to convert between different path styles? 😊]

  • אוביסידיאן לא מעדכן לבד Header links
  • זה גורם לכך שלעשות הרבה לינקים להדרים ללא ספק ישבור אותם בסוף אם הקובץ שלנו בעריכה מתמדת
  • הפתרונות שלי הם שניים:

  • מינימום לינקים להדרים - התחלתי להשתמש בזה קצת יותר מדי. צריך לשים את זה אך ורק כשיש חלק בקובץ שממש צריך להיות מקושר לחלק אחר בקובץ גדול - כלומר, כשזה ולא מספיק לקשר לקובץ באופן כללי. לא כל אזכור של "regexp" צריך להיות מקושר לכותרת בקובץ הבאש... אבל כדאי למשל לקשר את הקובץ העצמאי של regexp לכותרת של regexp בקובץ הבאש - כדי שבעתיד אדע שהידע הזה מפורט בכמה מקומות. באופן כללי - המטרה היא לא לקשר כל אזכור לידע המתאים - אלא רק לוודא שבחיפושים עתידיים, יהיה ברור איך ואיפה הידע מפוזר

  • להשתמש בתוסף "Fix Broken Links" שהורדתי, כדי לבדוק מדי פעם אם יש לינקים שנשברו... כדאי לזכור שלמדתי לפתוח Minimal Vault מהלפטופ - אז אני לא ממש ממש חייב לצמצם בתוספים. בכל אופן אני לא אוהב שיש מיליון though.

    [[ילדבוי]]