[Libreoffice-bugs] [Bug 128316] FIELDS: Allow date field with lower case letters

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #29 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to itt788 from comment #28)
> (In reply to Mike Kaganski from comment #27)
> > Field is, 
> [ ... ]
> > not a random text.
> This is such a harsh statement you do as response to my comment! If i hurt
> anyone here, be sure this is not intentional.

No, you haven't hurt anyone; and it looks like my use of word "random" might be
wrong/harsh, which is not intentional. What *I* tried to express was, that
unlike usual text that user types and edits at their will, being in full
control of any character of it (which I expressed as "random", but maybe the
word is improper; I'm not a native English speaker, sorry), field's text is
controlled by the field algorithm.

> Fields are used where the information users want in their document can be
> calculated by the computer. That is things like page numbers, arithmetic
> operations, dates...

Exactly.

> In my understanding Fields consist in two layers, first, the "code", to make
> the computer understanding what we want. Second, the way is is represented
> as per user's wish.

No. There is no "two layers" here, only one layer of "apply some algorithm to
some input data to create some sequence of characters". Field *usually* (except
for very special fields like ToC) does *not* care about representation of the
characters, it just inserts these characters into the character stream rendered
by its "owner", which is some text run. Representation of characters (font, its
effects, spacing, etc.) is performed on a layer unrelated to the field; but
note that the characters themselves are *never altered* on those outer layers.
By the way, the characters of other "random" (sorry for the word) text are
*also* not modified by those "representation" layers - which only apply
formatting.

The process of *modification* (say, replacing one character "a" with another
"A") is not part of representation, anyway. In normal text, it's performed when
user types something, or otherwise edits (e.g., using automatic edit tools like
spell checking); in that process, user *modifies text*, not modifies
representation. And again: *field's* sequence of characters is *calculated, not
typed*, hence you may not edit it.

That said, we have *some* fields that allow free editing of their calculated
content: namely, ToC. You may unprotect the field, and type/delete/replace
things there at will. But to make that possible, the field must be "calculated
once": what I mean is Writer does not re-calculate the field on every change of
the document, but calculates it *only* on first insert, and then on explicit
commands to update it. Even save-and-reload does not cause its re-calculation;
that's why you may have totally out-of-sync ToC in your document, if you forget
to refresh it manually. In this case, when Writer keeps the cached text of the
field which will not be modified until the next explicit command, it's
reasonable to allow user to change that cache at will ... and user should
realize that any manual changes there will of course be lost when the field is
updated.

But for *any* auto-updated field, that does not make sense. Every change in a
document, like typing a character somewhere, may trigger automatic refresh of
the field text, which would ruin any manual changes to the cached text. That is
*wanted* and *expected*, *correct* behavior; it would be *wrong* and a *bug*
for a page number field, or a cross-reference field, or any of the multitude of
other fields, to not change in those cases. Even for a "fixed date" field,
which you may think as "calculated once", it's not so: it's calculated from a
fixed date, but variable current locale of the enclosing text - thus when you
change the language of the outer text, it will automatically re-calculate its
string. So it's also auto-calculated data, and should not allow free-form
modification of its cached string.

How Word does it is a different thing. The two suites are built around very
different concepts; and it's not necessary that a workflow in one of them
translates directly to the same workflow in the other. It's done where
applicable, but not universally.

Also please don't repeat the "for French, it's broken" (which I don't deny) as
proof of "the solution that *I* suggest is the only suitable". Yes, the problem
needs improving, but that doesn't mean that it only has *that* solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201213/38687925/attachment.htm>