want to be able to display the set name directly when the link is displayed, rather than using an alias

[jiajiala]

Hopefully like this

Direct display becomes the name specified by the rule
Not by changing the alias

Because sometimes when an alias is needed, it can't be used and will be replaced by a plugin

[snezhig]

Honestly, I did not get the idea.
Do you mean just replace shown title in view mode without actual editing a file like Note Feature does?

[jiajiala]

As shown in the file above, 23_0828_200815___Test

You want him to appear as Test directly in the edited document, just as it appears as Test inside the folder.

Instead of having it display as Test, it has a form like [[23_0828_200815___Test|Test]]

Because it would make my other work difficult

For example, if I want it to appear in a document as Test Typing, I will use [[23_0828_200815___Test|Test Typing]]

However at this time

1 If I select "Replace all links" in the plugin then [[23_0828_200815___Test|Test Typing]] that I defined myself will be modified

2 If I select "Replace only links without aliases" in the plugin then although my own definition of [[23_0828_200815___Test|Test Typing]] will not be modified, But if I were to change the file name to 23_0828_200815___Test ABC then it would appear as ABC in most of the files but because "only replace links without alias" was selected it would not appear as ABC in all of the files

None of these methods cover every situation

Envisaged method:

[[23_0828_200815___Test]] is displayed as Test in the file unless it has a custom alias, such as [[23_0828_200815___Test|Test Typing]] is displayed as Test Typing

In this way

1 I can customize the alias I want to use in a particular article

2 Once I change the file name, the display will change with the file name, except for the part where I customize the alias

---

如上图的文件，23_0828_200815___Test
希望他在编辑的文档中直接显示为Test，就像它在文件夹内显示为Test一样。
而不是通过 [[23_0828_200815___Test|Test]] 这样的形式来让其显示为Test
因为这种方式会让我的其他工作不好进行
比如 我希望他在某个文档中显示为 Test Typing 我就会利用到 [[23_0828_200815___Test|Test Typing]]
然而这个时候
1 如果我选择 插件中的 “替换全部链接” 那么我自己定义的 [[23_0828_200815___Test|Test Typing]]会被修改
2 如果我选择 插件中的 “只替换没有别名的链接” 那么虽然我自己定义的 [[23_0828_200815___Test|Test Typing]] 不会被修改，但如果我要修改文件名字变成 23_0828_200815___Test ABC 那么它应该在大部分文件中显示为 ABC 然而因为选择了“只替换没有别名的链接” 导致所有文件中的显示都不会被修改成为 ABC

以上的方法都不能涵盖所有情况

设想的方法：
[[23_0828_200815___Test]]直接在文件中显示为 Test，除非他有自定义别名，如 [[23_0828_200815___Test|Test Typing]] 则显示为Test Typing
这样
1 我可以自定义我想在特殊文章中用的别名
2 一旦我文件名字进行修改，那么除了我自定义了别名的部分，其他的显示都会随着文件名字的修改而修改

[ftvkyo]

@snezhig, I think I might understand the idea, let me know what you think about this.
@jiajiala, please tell me if I'm right.

My interpretation of the feature description

The goal may be to:

• Specify just the note filename in links as [[note-name]].
• Render the links using their title according to the plugin settings.

If that is the case, I have actually implemented something like that for personal use previously, and I would love to take this on.
If that's not the case, I'd actually create a feature request for it 😅
Overall I think this would be a very nice feature even if we don't find a way around the cons and the technical limitations (see below).
It would make sense to have it behind a feature-toggle either way, just like the existing plugin features can be toggled.

Edit: the feature suggestion is still the same, but I have to take my words back—I can't guarantee that I would take this on.
Thanks for your understanding.

Cons and pros, technical limitations

The main benefits are:

• No redundant custom link text necessary (although it still can be specified if desired).
• No need to update links when titles of referenced notes change.

There are some caveats, though:

1. When a link is inserted using an alias, the default behaviour is that the alias is automatically inserted as its custom text.
   This interferes with the desired behaviour of “no redundancy” and may require intercepting the link insertion process.
2. At the moment, I am not sure if it's possible to know whether a link had custom text set or not.
   It may be possible to do it based on CSS classes of the link element, if they are actually different in that case.
   In my previous implementation it was good enough when I compared link text to its href attribute, but this is a bit hacky, and does not work with heading and block links.
3. The implementation is based on plugin.registerMarkdownPostProcessor.
   I have observed that the links may not get re-rendered immediately even when switching to and from edit mode or when the note is updated far from the link site.
   However, it still worked well enough.

Here is an excerpt from my code.
It is not very useful without the surrounding APIs I have there, but it should illustrate the idea.

Excerpt auto-alias.ts

import { MarkdownPostProcessorContext, MarkdownRenderChild } from "obsidian";

import Logger from "@/util/logger";

import ApiNote from "@/api/note";


let lg: Logger | undefined = undefined;


class AliasLink extends MarkdownRenderChild {
    constructor(
        readonly containerEl: HTMLElement,
        readonly alias: string,
    ) {
        super(containerEl);
    }

    onload() {
        this.containerEl.innerText = this.alias;
    }
}

export default function AutoAlias(
    element: HTMLElement,
    context: MarkdownPostProcessorContext,
) {
    if (!lg) {
        lg = ftvkyo.lg.sub("auto-alias");
    }

    // Find all internal links
    const links = Array.from(element.querySelectorAll<HTMLElement>("a.internal-link"));

    if (links.length > 0) {
        lg.info(`Found ${links.length} internal links.`);
    }

    for (const link of links) {
        const href = link.getAttribute("href");
        const filename = href + ".md";

        // Only process links that have the same alias as href
        if (link.innerText !== href) {
            lg.info(`Link has an alias already`);
            continue;
        }

        const note = ApiNote.fromPath(filename);

        if (!note) {
            lg.info(`Note not found`);
            continue;
        }

        if (!note.h1) {
            lg.info(`No h1 found`);
            continue;
        }

        lg.info(`Found h1 "${note.h1}"`);

        context.addChild(new AliasLink(link, note.h1));
    }
}

[daemonspring]

@ftvkyo I can't confirm what the OP wants, but your interpretation is exactly what I am looking for and essential for my desired workflow.

Custom link text should never be changed automatically, because this may lead to [[737|surprising and destructive]] changes to user content.

See Also:: [[401]]

The See Also link is supposed to refer directly to a note, so it makes sense to display (in the reading and live-preview modes) whatever its current human-readable title is instead of an unreadable unique ID. Custom text is content though and I never want to mess with it, so I can't use the Note Link feature to solve the problem. If I use that I completely lose the option for custom text that isn't a note's name. I really do have two types of link so I need two different behaviours.

Also, imagine if See Also was a bare link too:

[[101]]:: [[401]]

If I wanted to rename the See Also field (now defined in the file 101) to Related, it would now be incredibly easy and only require editing the frontmatter of one file. Nothing that relies on those IDs would have any chance of breaking. Git diffs for the vault wouldn't be full of renaming noise. This would be incredibly convenient for managing complex ontologies. Resolving conflicting field names would be much easier if my field names are defined in their own uniquely identified notes.

Overall, I want to be able to rename things easily without breaking anything or updating hundreds of files and the only way to support that is stable links in the source (avoiding filename changes) paired with human-readable display of those links.

[ftvkyo]

@daemonspring

[[101]]:: [[401]]

That's a Dataview inline field, right?
I imagine Dataview queries would have to specify [[101]] as the field name?
Seems like a very interesting use case to me, and it does not require the plugins to be aware of each other.

@snezhig, do you think we should make a separate feature request ticket for this, considering the original intentions are unclear?

[snezhig]

I will return to this issue. I need to read all of this again and think.