Inconsistent names in links. Sometimes the folder is included in the name, sometimes not

Steps to reproduce

  1. Create some files in a subfolder.
  2. In another file, begin typing a link so that the auto-suggest pops up.
  3. Observe that some of the link names want to include the folder, and some don’t.

Expected result

Either all links should only have the name of the file or all links should have the name of the file along with the folder names. (I wish the folders were not part of the link name because doing so makes the link take up a ton of space. But either way, I’d like there to be consistency.)

Actual result

Inconsistent link naming!

Environment

  • Operating system: macOS Catalina 10.15.4
  • Obsidian version: 0.6.7
  • Using custom CSS: The Nord theme (one of the community themes).

Additional information

I recorded the bug because seeing is believing. It’s at the beginning. (I recorded two bugs in this video, and this bug is the first one.)

In the hope that this helps, I’d also like to note that I think this might be directly or indirectly related to – but not the same as – the following bugs:

  1. References not updated when moving/adding files to folders
  2. Attachment folder path does not persist after renaming
1 Like

Hi, If you read the discussion in those reports, you will realize that is not incosistent behaviour.
It’s a design choice. We still have work to do to get it fully functional.

First bug:
you also appear to have another bug that we will fix in 0.7. (one of your files ends in .md in the suggestion. it shouldn’t)
https://forum.obsidian.md/t/obsidian-does-not-handle-well-note-titles-containing-non-breaking-space/821/5

Second bug: not really a bug.

Thanks for the report!
You will benefit from 0.7!

Thanks for the timely reply!

Are you referring to this part of prior conversation?

I understand and agree with the design choice to have Obsidian use only the file name when possible, falling back to using the whole file address only when not doing so would create ambiguity.

However, that doesn’t explain what I recorded. There’s no such ambiguity with the files in my demonstration. The files have universally unique names. Therefore, there is no current general explanation for why it happened. The behavior is not consistent with the design choice, which I believe makes it a bug.

There is also no current specific explanation for why it happened to one file but not the other in my demonstration. My hunch is that this can only be answered when the malfunction is acknowledged and understood. Hopefully when there is a general explanation, it will explain the specific behavior I observed. Or when there is a specific explanation for my situation, hopefully it will lead to a general solution.

(If you were referring to a different part of prior discussions than what I quoted, then I apologize. Please link me to correct comment if that’s the case.)

Once again, I am pretty sure that the problem you have is related to another bug (even if it is not immediately evident)
https://forum.obsidian.md/t/obsidian-does-not-handle-well-note-titles-containing-non-breaking-space/821/5

Please, check back when we release 0.7.

Also regarding the reference bug, we have plans to fix it along with general improvements to the linking system.

Yes, I see that bug. I linked to it in my original comment, and I also think I quoted the exact comment that you were referring to in your last comment. So please, before you begin another message with “Once again,” please hear me out because I’m trying to say why I don’t think what I’m asking was covered over there.

Over there, your answer was that the plan is for Obsidian to use only the file name in links when there’s no ambiguity. The folder is only to be added when there is ambiguity. The particular ambiguity is when there are files in different folders having the same name. Have I understood?

Here, the files I recorded in my demonstration have universally unique names (no other file in any folder has the same name). So, there is no ambiguity. Therefore, your answer over there does not address what is happening in my demonstration here.

Keep reading, please!

“But SquareBottle,” you’re probably thinking, “what I’m saying over there is that files with universally unique names won’t have the folder name added when 0.7 comes out. So, your issue goes away. Therefore, it does cover what’s happening here.”

So then, why am I still going on?

Over there, the person was surprised when a folder appeared at all. That’s why you explained the design decision. In other words, the perceived inconsistency of that thread was “Sometimes folder names are part of the links and sometimes they aren’t.” I agree that you cleared that up by explaining how it’s consistent with a conditional rule (use short file name when unique, use full file path when ambiguous).

Here, my surprise was that two files that seem to have the same relevant traits (namely, they both have universally unique names) are being treated differently. The perceived inconsistency is that the conditional rule that you described is not being applied according to the condition you defined. That you said that there is no inconsistency makes me think that you are overlooking this. What I recorded is inconsistent with the conditional rule.

“Okay, so it’s an inconsistency,” perhaps you are willing to concede, if only to satisfy me. (If not for even that, then for the purpose of the narrative I’m using. Please forgive me.) “Nothing else from my reply changes, SquareBottle. When we finish implementing the conditional rule in 0.7 as described in the other thread, your problem should disappear. So we’re done here.”

No, we aren’t! That doesn’t explain the other inconsistency captured in my demonstration: why the full file path was used for one file but not the other. The first inconsistency is about the conditional rule. This one is about how two files with the same properties but different file names are being treated differently. They should currently be treated the same – even though that means they “should” currently both be inconsistent with the conditional rule. Do you see the distinction now?

If not, then here’s my last try:

Imagine some robots are dancing to the beat of a song. The desired behavior is that they both clap to the beat’s fourth notes, so it’s expected that the claps will be evenly spaced (1, 2, 3, 4, 1, 2, 3, 4).

One day, a boy notices that the robots seem to be clapping twice on each beat (1-1, 2-2, 3-3, 4-4, 1-1, 2-2, 3-3, 4-4), they occasionally miss a beat, and one is snapping instead of clapping. The boy asks the seasoned robot maker about it, thinking it’s a malfunction for them to be clapping twice.

The robot builder replies, “No, I want them to clap once on the same beat for slow songs and twice on the same beat for fast songs. Pretty great, right? I need to tweak a few things because they miss beats now and then. I’ve already found the problem though, so come back tomorrow and they’ll get the rhythm right.”

“Okay! Yeah, that is great!” says the boy excitedly. “But why is that one snapping?”

“Like I said, come back tomorrow and they’ll clap on beat according to the rule about slow and fast songs,” replies the older man patiently.

“I get that. Or at least I think I do. But why is only one of them snapping? If they both have the same code, shouldn’t both or neither be snapping? I know it’s the same rhythm, but does that matter for this question?” asks the boy. He knows the robot builder said “they’ll clap on beat” tomorrow, and if that is entirely true, then there will be no more snapping. But from the context, he thinks the old man is focused on the rhythm and not on the question he actually asked: why is one robot snapping?

If you still believe that your replies (here and in the other thread) already answered my questions, then I will assume that you are correct and that I’m just misunderstanding or overlooking something. I will take up no more of your time if that’s the case. Thank you for considering.

I am not sure this is the greatest misundustanding ever.
I will try to explain one more time.

I strongly believe you have another bug (non breaking white space/unicode handling) that is affecting the way linking works.
0.7 will address that bug (Obsidian does not handle well note titles containing non-breaking space)
0.7 will not address the reference issues in here (References not updated when moving/adding files to folders), but I don;t think this is your primary problem.

As a quick test. Can you try renaming the note that is creating you issues “2020… My 30 day” to “Test”.

Now try to reference to “Test” in a new note and move it to a different folder.

Sure! Here’s the test you requested.

Because both files from the first video have the same kind of white spaces, I don’t yet see how this test addresses “why only one robot is snapping,” but either the answer will become clear to me or I’ll trust that the answer exists and that you know it even if it just won’t click for my brain.

I feel guilty taking up so much of your time and energy. My intention is to be helpful, and I really do think I’ve caught the scent of something fishy (similar to some other scents, but not the same). But at the end of the day, I’m an interaction designer and not a programmer. So, I can be content with deferring to you and letting go. I might not understand, but if you considered my each part of my previous post, then I believe you understand the problem and solution. At a certain point, it’s more than okay for an expert to say “trust me” to a layperson. Perhaps unsatisfying, but eventually necessary.

it’s ok, don’t worry. The problem with these whitespaces is that they look the same but they are not the same.

But I’m familiar with the varieties of whitespaces! The spaces in the file names are just regular ol’ push-the-spacebar-and-nothing-else spaces! And the files were made the exact same way!

UNLESS…

I thought I made them both in Obsidian 0.6.7, but perhaps I made one in 0.6.6 and I’m misremembering? And perhaps that older version of Obsidian used a different type of whitespace as its default space, somehow?

It’s also possible that Zettlr or Neuron did something. They’ve both accessed the files. It seems weird to me that they’d change the type of whitespace, but in the grand scheme of things, stranger things have happened.

It’s also possible that it’s something completely different and I’m just. Not. Getting. It.

You seem very confident that my question has been answered. I can put my confidence in you. :slight_smile:

1 Like