Steps to reproduce
If there is a space at the beginning of the line before the # sign in the heading, Japanese input using the IME on the line before the heading will not work properly:
text is converted and confirmed (ATOK), or the input stops(MS-IME, Google Japanese input) while typing characters.
If you delete the space before the heading, it works correctly.
Also, it seems to occur only when the editor setting for ‘fold indent’ is turned on, and not when it is turned off. So this may be an issue related to folding rather than heading.
↓↓text input doesn't work properly in this line
### heading 1
↑↑there is a `space` before `#`
- Operating system: Windows 10, Obsidian v0.14.12 both in LP mode and source mode.
can you post a screen recording of this happening in the sandbox vault?
In this case, I typed
1234 and tried to convert it into kanji(一二三四) by hitting space key a few times.
On the line before the normal heading, the conversion is correct. On the other hand, on the line before a heading with a space, the 34 entry is not accepted and the screen scrolls down when the space key is subsequently pressed.
The above is the behavior when using ATOK. If you use Microsoft IME, the same thing happens: the 34 entry is not displayed on the screen, but when you press the space key, the cursor jumps to the end of the line above (in this case,
### heading without a space) and the suggested conversions are displayed there.
The situation in which this occurs is the same, but the subsequent behavior seems to vary depending on the string being input, with patterns such as no input being accepted, the cursor jumping, or the string being unintentionally confirmed in the middle of input.
This does not happen in Sandbox either, if I turn off the fold indent in the settings.
It seems that the heading is irrelevant and can be generalized as “when folding indent is on, the input does not work correctly on the line before the indented line”.
Thanks for fixing the bug. However, I don’t know if this is a new bug with this fix or with other changes, but the situation seems to have worsened in v0.14.13. It hasn’t changed in v0.14.14 either.
However, there are many strange behaviors that cannot be reproduced consistently, making it difficult to report clearly.
The following behaviors have been observed sporadically. Sometimes it does not occur for a while, and sometimes it occurs multiple times in a row. I have the impression that it often occurs when I am typing long sentences or editing in a list, but I am not sure.
Same behavior as before
- No longer accepts input
- The cursor jumps.
- Conversion is confirmed by itself in the middle of typing.
Behavior different from the previous one
- Folding symbols（▼） sometimes appear in the middle of a line.
- Line breaks in lists sometimes do not work properly.
These problems have not been reproduced in Sandbox so far. I have the impression that the frequency of these problems is greatly reduced with safe mode on (but sometimes it occurs).
On the other hand, odd behaviors that is stably reproduced in Sandbox in v0.14.13 and 0.14.14 is
- When typing Japanese before a long list, the folding symbols in the list move left and right. Although this cannot be confirmed in the attached video (it may depend on the css and font), the text below the input line will move up and down a few pixels along with it.
- In a list, after typing a long Japanese sentence and pressing the space key to convert it, when the conversion is confirmed by one phrase at a time (Ctrl+N key in my case), the backward text may disappear and reappear each time.
(If this is likely to be a result of fixing the original bug, please consider rolling it back. The original bug only occurred in limited situations and could be worked around in the settings, but this one is causing major problems with typing).
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.