When you want the copied search results to properly link to canvases.
When generating a list of links based on a search and copying it to the clipboard, add the .canvas for the canvas file matches in the list so that the resulting links are valid.
Thanks!
The Obsidian supports using [[fileName.fileExtension]] to link any files within the vault without knowing the absolute or relative path of the files, in case there is no duplicated files named as fileName.fileExtension.
This is convinient, because the note, canvas and other attachment files can be moved to different folders within the vault by system file exlporer outside Obsidian.
However, in the search result, the generated link does not support this feature.
As shown in the following picture, without turning on the Show Path switch, the copied search results will generate links as [[1]] and [[2]], which will be interpreted as links to 1.md and 2.md rather than 1.canvas and 2.canvas
However, by turning on the Show Path switch, the flexibility of using the link is hurt, as the link will become invalid if the location of the target files are changed outside Obsidian, e.g. the file is moved from one folder to another folder.
I think the copy search result pane can provide an option to provide a compomised solution: adding a swith to toggle the file extension in the search results list. So that the link generated by copied search result can be as useful as the ones in other part of the obsidian.
Surprised to see this buried as a Feature Request, this is definitely a bug IMO.
This will be fixed in 1.8.2
Cool! I agree. I was in the habit of erring on the side of creating a feature request or help topic. Then later I would create a bug report if needed, and I remembered. In this case, I guess canvas was kind of new and I had created a ton of other canvas requests, so it felt somehow less urgent. At the time I think canvas link functionality had just been improved, so marking it as a bug felt wrong. Anyways, regardless of all my unnecessary reasoning here, I will say that it’s helpful to understand the distinction generally going forward and try to keep in mind what would be a bug once the feature is fully implemented. Thanks!
It is really a suprise for me to see that this issue is fixed in the Release Note of v1.8.2!
Thank you!
Actually, I really hesitated whether to post it weeks ago. The original post seems so lonely, 
for years. So at first, I finished a BR on this, but at the last minute, I deleted it. However, very lucky, with a second thought, I pasted the relavent content here.
To be honest, I even don’t expect anyone may notice the update.
But now, look! It is picked out and the problem is solved!
The attempt is worthy! I’m so happy!
Thank you!
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
