Suppose I have some autotext entry with a certain shortcut. If I type in that shortcut and press F3, it should be replaced with the autotext entry (well, that and the gratuitous newline, see bug 53023). However, if I have an extra space character after the shortcut, and my caret is just after that space - F3 will not be match my shortcut and I'll get an error message.
I confirm that behaviour, but for me it is expected behaviour, because - for example - there is an autotext for "DT", but not for "DT ". Perhaps it's an enhancement request.
(In reply to Dieter from comment #1) > I confirm that behaviour, but for me it is expected behaviour, because - for > example - there is an autotext for "DT", but not for "DT ". It is very common for someone to press the space key at the end of the word, and only then to press the F3 to change the autotext. I believe it is extremely uncommon for someone to use an autotext identifier ending in space; in fact, I challenge you to find a single example of an identifier being in use for autotext both with a trailing space and without it. > Perhaps it's an enhancement request. The default behavior should most certainly be ignoring a trailing space. I don't actually believe what you described is your expected behavior, in the sense that I'm assuming you don't actually have any autotext identifier ending with space; which means that if you do ever press D3 after "DT ", it is only because you want the "DT" autotext and not for another reason. Or maybe this is a moot point, since you never press F3 after a space character? Correct me if I'm wrong.
(In reply to Eyal Rozenberg from comment #2) > It is very common for someone to press the space key at the end of the word, > and only then to press the F3 to change the autotext. I believe it is > extremely uncommon for someone to use an autotext identifier ending in > space; So we have different opinions here. > which means that if you do ever press D3 after "DT ", it > is only because you want the "DT" autotext and not for another reason. If you man F3 I say yes. I press it, because I want the "DT" autotext, because that's the function of the F3 key. > since you never press F3 after a space character? That's true, because I won't expect, that this works.
I would turn the argument around: the autotext dialog refuses to accept spaces for shortcuts. And for good reasons as I never heard of shortcuts with spaces.
(In reply to Heiko Tietze from comment #4) > I would turn the argument around: the autotext dialog refuses to accept > spaces for shortcuts. And for good reasons as I never heard of shortcuts > with spaces. So... can you confirm, then? My typing instincts often emit the space after the shortcut - the way my hands indicate they're done with a word - before deciding to press F3.
Neither Dieter or me expect white-space being part of shortcuts. Consider also the word finalization, some procedures run like spell checking and auto correction. => NAB
(In reply to Heiko Tietze from comment #6) > Neither Dieter or me expect white-space being part of shortcuts. Dieter said that in his opinion this could be an enhancement. So, not enough grounds for closing this. > Consider also the word finalization Not sure what you mean by that. > some procedures run like spell checking and auto correction. => NAB I'm not sure how these things relate to my request. When you've typed some text and press the autotext shortcut (F3), two things can happen: A replacement, or nothing. Now, think about it: Why would I press this shortcut unless I expect a replacement? That's my extremely-likely intent. Now, if there's a "perfect" match for an autotext key in the preceding text, there's no dilemma and you just replace. And if we have no idea what to replace with, we shouldn't just guess. Also, if there are two entries which are just as likely, one could also argue we shouldn't arbitrarily choose one. But - in this case, we have a single candidate entry, and an extra space. What is more likely? That I would rather LO not replace anything, or that what I want is for the space to be elided? You will be hard-pressed to claim the first response is what the user wants, or expects.
I see no benefit to including the trailing space for the F3 Autotext shortcut handling, and a serious downside of inadvertent replacements by allowing any non-exact matching. The AutoText dialog <Ctrl>+F3 shortcut field does not allow/accept space (or other whitespace that I tried) for defining a AutoText passage. Behaving as implemented. -1 to any change, and otherwise => NAB
(In reply to V Stuart Foote from comment #8) > I see no benefit to including the trailing space for the F3 Autotext > shortcut handling The benefit is that half the time I type an autotext entry key, I also type a space, because I'm used to typing a space after every word. >, and a serious downside of inadvertent replacements by > allowing any non-exact matching. But that's the whole point - it's not inadvertant - it's advertant! It is what the user asked for. > The AutoText dialog <Ctrl>+F3 shortcut field does not allow/accept space (or > other whitespace that I tried) for defining a AutoText passage. Even better - that means that there is even less doubt about what the user wanted. Now, if someone were to proposed generalized fuzzy matching - that certainly has downsides and I'd not make it the default behavior. Here we're talking about a very specific case where user intent is clear.
OOo 3.3 used to ignore the space and move the cursor to before the space, ending with an empty selection and an empty string as a shortcut. OOo 3.3 wouldn't allow spaces in the Shortcut field either. Since 6.4 and commit 810cddee6d2ef0f4057337d699a1a55323faa1ba for bug 126589, it includes the space and the preceding string. Confirmed in a recent master build that pressing F3 will take the space along with the preceding string as the shortcut _even though the AutoText dialog's Shortcut field does not allow spaces_. I agree with Eyal that any space right before the cursor should be ignored, given that: - no space is allowed in shortcuts, so there is no space for confusion – pardon the pun; and - before 6.4, the space would be ignored And Stuart seems to agree too in Comment 8 – was there some misunderstanding? Mike, a you fixed bug 126589, can you please have a look?
(In reply to Stéphane Guillou (stragu) from comment #10) IMO, and according to *my* instincts - a function (F3) should apply to what is touching it. The same way, my instincts tell me to put full stop or comma immediately after I stopped typing the last word, not after a space, and not expecting Writer to clean up after me. Also wrt "It is very common for someone to press the space key at the end of the word" - IMO, a shortcut is *not* a word, but is explicitly chosen start of a command, so "lorem[F3]" is a command, while "lorem " is a word. Commands are specific sequences, I dislike increasing "intellect" of recognizing them, which could look innocent, but is likely to give problems in unexpected situations.
Having said that - so as an UX feedback, it's -1 from me - if someone decides to "fix" this to skip spaces to the left, then doers decide, as always.
(In reply to Stéphane Guillou (stragu) from comment #10) > OOo 3.3 used to ignore the space and move the cursor to before the space, > ending with an empty selection and an empty string as a shortcut. > OOo 3.3 wouldn't allow spaces in the Shortcut field either. Also note that this is not strictly correct. Before that fix, F3 didn't simply allow space - it looked for the *closest word*. So it could choose the *next* word, like in lorem |ipsum where | denotes the caret position - here it would try to convert "ipsum". Indeed, when typing new text, this isn't obvious. If I implemented what is asked here, I would try to convert my code pWrtShell->PrvWrd(true); which selects back the same way as pressing Shift+Ctrl+ArrowLeft, into the sequence of Ctrl+ArrowLeft (which would go to the start of the previous word without selecting), and then selecting the closest word, as before my change: pWrtShell->PrvWrd(false); pWrtShell->SelNearestWrd();
(In reply to Mike Kaganski from comment #13) > pWrtShell->PrvWrd(false); > pWrtShell->SelNearestWrd(); heh, and that would indeed break my fix, disallowing to only select back in the middle of a word.
... so just do the "select nearest word" after testing that the key has a trailing space.
(In reply to Mike Kaganski from comment #13) > Also note that this is not strictly correct. Before that fix, F3 didn't > simply allow space - it looked for the *closest word*. So it could choose > the *next* word, like in > > lorem |ipsum > > where | denotes the caret position - here it would try to convert "ipsum". > Indeed, when typing new text, this isn't obvious. My use-case of interest is when there is no next word - I'm typing something, and at the end of the paragraph, just after what I've just typed, I press F3. So - I would actually not mind too much whether, in the particular case you described, the chosen shortcut is "lorem" or "ipsum". I prefer it to be lorem but it's a weak preference.