🐞 Strange Behavior of Callout Type Autocompletion

[RyzenFromFire]

Check for existing bug reports before submitting.

• I searched for existing Bug Reports and found no similar reports.

Expected Behavior

I type >[! and a dropdown list of admonition types appears. I can type more characters to search/narrow down the list of types. When I press Enter (or alternatively Tab, doesn't matter to me), the currently selected one is autocompleted and my cursor is placed at the end.

Current behaviour

I type >[! and a dropdown list of admonition types appears. I can type more characters to search as desired, but the first character I type is always kept, and then the autocompleted type is concatenated. For example, if I type >[!n and then select the note type, the result is >[!nnote] (with my cursor one space after the bracket - that part is fine).

Furthermore, in this case, pressing Enter (or left-clicking) to confirm the autocompletion doesn't work in a clean vault for some reason. That is, I can't actually autocomplete.

---

If I only type >[! with no additional characters, then select a type, a newline is inserted. Like before, in a clean vault, pressing Enter or clicking to confirm doesn't do anything.

---

If I type a space >[! , then select a type, the selection menu remains open, which can cause "chaining" of the part of the admonition declaration after the part already typed (ex. note]):

...ad nauseum

Unlike the previous two cases, pressing Enter to confirm the autocompletion works in a clean vault, exhibiting the same behavior described here.

Reproduction

1. Open any vault and file.
2. If the Admonition plugin is not already installed, do so.
3. Using live preview or source view mode, type >[! followed by: 1. some other character that is part of a valid admonition type, 2. nothing, or 3. a space.
4. The admonition autocomplete selection menu appears. Select one by pressing Enter or clicking on it.
5. Depending on what you did in Step 3, the behavior corresponding to the case described above occurs.

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Obsidian Version Check

v1.5.12 and v1.4.16

Plugin Version

10.2.0

Confirmation

• I have disabled all other plugins and the issue still persists.

Possible solution

No response

[valentine195]

I unfortunately can't recreate this at all. I will keep investigating.

[IsuminI]

Hello!👋 We are a team of university students doing an open source contribution practice.
Would it be okay if we take a look and submit a PR for this? 😊

[valentine195]

@IsuminI feel free :)

[Tw1ZZLER]

This still an issue I am having as well. It looks like #355 fixes the issue, and I would love to see that merged!

[RyzenFromFire]

I unfortunately can't recreate this at all. I will keep investigating.

@valentine195 forgot to post this earlier, but @Tw1ZZLER and I found out that it happens only if you don't put a space between the > and the [. e.g. >[!note]. Using a space, like > [!note], works perfectly fine. This also lends insight into why the first character is duplicated in the first case I mentioned in the original issue - it's probably an offset-based issue caused by an assumption that there must be a space between the > and the [.

[valentine195]

Thanks for looking into this. Does the native callout require the space? If not then this is a bug that it triggers and renders without it. Otherwise I'll need to support the lack of space properly.

[RyzenFromFire]

Seems like native callouts render the same either way (with space or without). So it should probably be supported/checked for properly. I haven't tested #355 personally, but it seems like it might fix it, as @Tw1ZZLER said.