After entering an autotext-shortcut, there must be a white space before pressing F3 -> this is impractical. It would be better if the text BEFORE the cursor was interpreted as an autotext-shortcut (this is how it works in MS Word).
Example (AT = Autotext-Shortcut, [F3] = Keypress) AT[F3] improvement -> works, but is impractical while editing an existing text AT[F3]improvement -> is misinterpretet as autotext-shortcut "ATimprovement"
I confirm it with Version: 6.4.0.0.alpha0+ (x64) Build-ID: 3e64065612acec2eb29aa21e2b515953422256d7 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded There must be a space between Autotext-Shortcut and the following word.
https://gerrit.libreoffice.org/80419
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/810cddee6d2ef0f4057337d699a1a55323faa1ba tdf#126589: only consider text to the left of cursor as AutoText short name It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike, I confirm, that a blank space is no longer needed. But the problem is now, that LO always adds a paragraph break after AutoText. Is this the intended behaviour? For some AutoText this is very practical, for other it is not.
(In reply to Dieter Praas from comment #5) > But the problem is now, that LO always adds a paragraph break after AutoText. > Is this the intended behaviour? For some AutoText this is very practical, for > other it is not. Do you mean that this has changed after the fix mentioned in comment 4? If this existed before, then that should be a separate issue.
(In reply to Mike Kaganski from comment #6) > Do you mean that this has changed after the fix mentioned in comment 4? If > this existed before, then that should be a separate issue. It's also in older versions. Sorry. => VERIFIED FIXED