Hamza 99f92f4a28 range.setValues: parse: false stores a string as the text it is (#2255) ...

Every string in `values` went through typed input, which reads it with en-US
rules, and nothing said so:

    "05.04.2026"  (dd.mm.yyyy)  → the date 4 May 2026
    "02/11/2026"  (dd/mm/yyyy)  → the date 11 February 2026
    "2.500"       (thousands)   → the number 2.5
    "4.25 %"      (text)        → 0.0425, formatted 0.00%

A workbook built from Turkish-format exports therefore held different values
than the script put in it, and the only way to notice was to read the saved
file back cell by cell.

`parse: false` stores every string as the text it is. A formula is still a
formula — `=` means a formula in a cell, and the ticket asks for that — and
numbers, booleans and null are unaffected either way. A leading apostrophe is
part of the text rather than the marker that makes it text, since nothing is
being marked.

The default is unchanged: `parse` is absent in every existing call, and those
calls behave exactly as before. A `parse` that is neither true nor false is a
usage error rather than a quiet default.

The test pins both sides — the swapped date, the decimal point and the
percentage under today's default; each of the six strings stored verbatim with
`parse: false`, with `=1+1` still calculating 2; numbers and booleans either
way; and the refused `parse` values. Without the change the first string comes
back as a date.

2026-10-22 18:05:53 +05:00

..

examples

fix: satisfy stricter clippy lints CI's newer stable toolchain catches

2026-10-12 02:52:07 +02:00

src

range.setValues: parse: false stores a string as the text it is (#2255)

2026-10-22 18:05:53 +05:00

tests

Integration: track t14

2026-10-22 03:05:30 +00:00

Cargo.toml

Engine: file.open decrypts password-protected workbooks (#11)

2026-10-11 23:29:28 +02:00