https://bugs.documentfoundation.org/show_bug.cgi?id=114773

Mike Kaganski <mikekagan...@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|libreoffice-b...@lists.free |mikekagan...@hotmail.com
                   |desktop.org                 |

--- Comment #25 from Mike Kaganski <mikekagan...@hotmail.com> ---
https://gerrit.libreoffice.org/c/core/+/147997

The implemented solution is:
Keep the hack introduced in tdf#44282, but only add the space if the next token
is "entry text", and also if the entry number does not end with a space or a
tab.

This allows the following situations:

1. The problem from bug 44282 - the existing ToCs without any space token
between the number and the text will keep working as desired, with the space
added automatically.
2. The problem from comment 0 (attachment 132787) had two problematic places:
2.1. There were two space characters inserted between [E#] and [E]. After
updating, the ToC had three spaces between those elements.
2.2. There was a [E#]-[#] sequence. After updating, it was shown as 2 -1.
Both problems get fixed, because in both cases, since the next element after
[E#] is not [E], but a text (either two spaces, or a dash), the automatic space
will not be added.
3. Comment 9 suggests a tab between [E#] and [E]. It is possible now, and
again, since the next after [E#] will be [T], not [E], the automatic space will
not appear. Whether it should become a default or not is a different thing, a
topic for UX; I would think it's questionable, but technically no problem
anymore.
4. Comment 24 also mentioned possible spaces as a postfix of the number itself,
which would result in a double space. Since the change checks the last
character of the number, this will also prevent the extra space.

Wrt #3, I think that an alternative solution (mentioned in comment 23) - i.e.,
having the *space* explicitly between [E#] and [E] by default - is not optimal,
because visually, the empty text placeholder between those elements is
indistinguishable form the placeholder with a space character.

All in all, I hope that this will be clever enough to avoid 99.9% of possible
problems; I consider a wish to really have the number merged to the following
entry text (which is impossible in the current and new situation) to be
~improbable to consider.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to