Giter Club home page Giter Club logo

Comments (8)

pjkaufman avatar pjkaufman commented on June 17, 2024

Hey @redactedscribe , I am not 100% sure what you are expecting to happen. Based on what has been stated, it sounds like you expect [ or ] to be valid in a wiki link. It is my understanding that it is not valid.

from obsidian-linter.

redactedscribe avatar redactedscribe commented on June 17, 2024

I don't know why text after a | in a wikilink or embed has the space after the |, but not before it. I'm not sure why this happens at all. My expectation is that it shouldn't happen, or if it is indeed expected, then to remove both the space before and after the |.

[ or ] in a wikilink is valid as far as I know. I only mentioned it to show that the space after the | is no longer removed if the wikilink contains a pair of square brackets, which could help identify why this is happening.

from obsidian-linter.

pjkaufman avatar pjkaufman commented on June 17, 2024

So it looks like there are two separate things that you are referring to here. The first is space is not being trimmed from before the | in wiki links. I believe this is intentional. The rule in question is remove-link-spacing. It is designed to solely remove extra spaces in the display text. That is why any spaces before the | are left as is.

As for [ and ] being in a wiki link, this is the first I have heard of it being valid in a wiki link. But the reason that would not be removing whitespace is because the Linter uses regex to determine what is a wiki link. Having [ or ] in it likely causes that regex to not match the wiki link thus it gets ignored for all wiki link related ignores and actions.

from obsidian-linter.

redactedscribe avatar redactedscribe commented on June 17, 2024

So it looks like there are two separate things that you are referring to here. The first is space is not being trimmed from before the | in wiki links. I believe this is intentional. The rule in question is remove-link-spacing. It is designed to solely remove extra spaces in the display text. That is why any spaces before the | are left as is.

Should something be done about this? [[Note |the note]] is valid, but when reading the source, which I primarily work in, it looks off. A pre-existing rule could cover this, maybe by expanding the scope of remove-link-spacing which you mentioned, which by its name sounds like it should do this already.

If that were the case, maybe in addition to this rule removing the spaces from the mentioned wikilink (and embed) examples e.g. [[Note |the note]], also remove them from URLs in Markdown links e.g. [text]( #header ) and [text2]( https://obsidian.md/ ). The goal would be to have no pre or post spacing in wikilinks or Markdown links (for both the text and link parts).

Alternatively to expanding remove-link-spacing's scope, the introduction of a second remove-url-spacing rule to handle it (which is a bit ambiguously named along side remove-link-spacing, I'm not sure what else it could be named). It would make more sense I think if remove-link-spacing was named remove-link-text-spacing and the new rule remove-link-spacing, but I'm guessing that would cause backwards compatibility issues for users.

As for [ and ] being in a wiki link, this is the first I have heard of it being valid in a wiki link.

It was only an assumption on my part really since e.g. [[Note [2024] foo]] hasn't given me any issues, but upon testing, [[Note [2024]]] does break (because nothing separates 2024's closing ] and the closing brackets of the wikilink ]]. It's inconsistent and probably therefore invalid and you imply.

from obsidian-linter.

pjkaufman avatar pjkaufman commented on June 17, 2024

Should something be done about this? [[Note |the note]] is valid, but when reading the source, which I primarily work in, it looks off. A pre-existing rule could cover this, maybe by expanding the scope of remove-link-spacing which you mentioned, which by its name sounds like it should do this already.

The name may be a little ambiguous, but I believe that the description explains exactly what it does:
Removes spacing around link text.

If that were the case, maybe in addition to this rule removing the spaces from the mentioned wikilink (and embed) examples e.g. [[Note |the note]], also remove them from URLs in Markdown links e.g. [text]( #header ) and [text2]( https://obsidian.md/ ). The goal would be to have no pre or post spacing in wikilinks or Markdown links (for both the text and link parts).

Wiki links I can understand getting spaces added because obsidian does that by default. However you would have to manually add this to markdown links, so that is much less of a concern in my opinion, though it may be worth considering.

Generally, markdown links are a lot easier to handle than wiki links. When a note name ends in a space like Note what happens to the wiki link name? Does it add an extra space or does it somehow get handled and removed so the user does not have to deal with it? I ask because normally for wiki links, the file name needs to be in the wiki link. So if the wiki link name ends in a space then no trimming of wiki link file names is possible because that could break a wiki link.

Alternatively to expanding remove-link-spacing's scope, the introduction of a second remove-url-spacing rule to handle it (which is a bit ambiguously named along side remove-link-spacing, I'm not sure what else it could be named). It would make more sense I think if remove-link-spacing was named remove-link-text-spacing and the new rule remove-link-spacing, but I'm guessing that would cause backwards compatibility issues for users.

That is possible, but it would cause backwards compatibility issues. I would prefer to avoid that if possible since things can easily go wrong with this.

from obsidian-linter.

pjkaufman avatar pjkaufman commented on June 17, 2024

I will say that from testing out the wiki link scenario with it ending in whitespace it seems to rename the file and trim the whitespace. I am not sure I like that approach when someone actually intends to end a file name with whitespace, but it does seem like it would prevent the issue with having to keep ending whitespace in wiki links.

from obsidian-linter.

redactedscribe avatar redactedscribe commented on June 17, 2024

The name may be a little ambiguous, but I believe that the description explains exactly what it does:
Removes spacing around link text.

A bit off topic: I appreciate good documentation, so that's great, thank you, but if having a more accurate rule name can prevent me needing to reference it, that's even better.

Wiki links I can understand getting spaces added because obsidian does that by default. However you would have to manually add this to markdown links, so that is much less of a concern in my opinion, though it may be worth considering.

To amend the stated goal, I'm simply in favour of the wikilink looking consistent: Either no pre and post space, or one on each side of |.

If I've understood you correctly, if Obsidian is already adding a space to wikilinks, then maybe an edge case to ensure a single space is added / exists post the vertical bar: {space}|{space}? But maybe there are users out there that are strongly in favour of no spaces: |? I'm not sure if one or the other is "more standard".

When a note name ends in a space like Note what happens to the wiki link name? Does it add an extra space or does it somehow get handled and removed so the user does not have to deal with it? I ask because normally for wiki links, the file name needs to be in the wiki link. So if the wiki link name ends in a space then no trimming of wiki link file names is possible because that could break a wiki link.

Is it even possible to end a note name (file) with a space? Perhaps on *nix systems, but it's also doubtful that a file ending with a space is used in any practical manner. Linter stripping it would be safe I think, and if it breaks someone's link, and once they notice the issue, it's probable that they'd want to fix their note name instead of keeping the space in the wikilink.

That is possible, but it would cause backwards compatibility issues. I would prefer to avoid that if possible since things can easily go wrong with this.

👍

from obsidian-linter.

redactedscribe avatar redactedscribe commented on June 17, 2024

Made an edit to the OP:

Edit: It appears to be valid to have a literal vertical bar within the alternate text (at least, Obsidian continues to render as expected), e.g.: ![[image.png|Foo | Bar]], so only the first vertical bar splitting link from alternate text should be manipulated by Linter.

from obsidian-linter.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.