You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
thielema opened this issue
Oct 23, 2024
· 2 comments
Labels
A-BUGSomething wrong, confusing or sub-standard in the software, docs, or user experience.cliCommand line parsing, options, arguments and suchlike.i18nInternationalisation/localisation-related.
I have a journal encoded in Latin-1. I can watch it like so:
$ iconv -f latin1 hledger-journal
~ monthly from 2024-01-01 Periodic
Forderung 42 Euro
Erlös
2024-01-01 Bla
Bank 23 Euro
Forderung
Please note the umlaut "ö" in "Erlös".
Now, for short outputs the local encoding is respected, for long output is encoded in UTF-8, even if written to a file.
$ LANG=de_DE hledger print -f hledger-journal -e 2024-02-10 --forecast >hledger-journal-printed
$ iconv -f latin1 hledger-journal-printed
2024-01-01 Bla
Bank 23 Euro
Forderung
2024-02-01 Periodic
Forderung 42 Euro
Erlös
This is the expected result. LANG=de_DE switches to Latin-1 encoding for this one run of hledger.
Now a longer output:
$ LANG=de_DE hledger print -f hledger-journal -e 2024-10-10 --forecast >hledger-journal-printed
$ iconv -f latin1 hledger-journal-printed
2024-01-01 Bla
Bank 23 Euro
Forderung
2024-02-01 Periodic
Forderung 42 Euro
Erlös
2024-03-01 Periodic
Forderung 42 Euro
Erlös
...
I think it is not a good idea to have different encodings depending on the output length. For piping to a file there should not be a pager involved, at all.
My preferred solution would be to always use the local encoding, as it was the case until now.
The text was updated successfully, but these errors were encountered:
That’s certainly surprising behaviour. Thanks for the report.
Since enabling this feature I’ve documented the logic in runPager. It’s probably still too weak at detecting when to use a pager (compared to our ansi colour detection, eg, which is aware of pipes).
There might also be a problem with loss of encoding when legitimately using a pager, it sounds like.
simonmichael
added
A-BUG
Something wrong, confusing or sub-standard in the software, docs, or user experience.
i18n
Internationalisation/localisation-related.
cli
Command line parsing, options, arguments and suchlike.
labels
Oct 24, 2024
A-BUGSomething wrong, confusing or sub-standard in the software, docs, or user experience.cliCommand line parsing, options, arguments and suchlike.i18nInternationalisation/localisation-related.
The following applies to hledger/HEAD (fa3676d).
I have a journal encoded in Latin-1. I can watch it like so:
Please note the umlaut "ö" in "Erlös".
Now, for short outputs the local encoding is respected, for long output is encoded in UTF-8, even if written to a file.
This is the expected result.
LANG=de_DE
switches to Latin-1 encoding for this one run ofhledger
.Now a longer output:
I think it is not a good idea to have different encodings depending on the output length. For piping to a file there should not be a pager involved, at all.
My preferred solution would be to always use the local encoding, as it was the case until now.
The text was updated successfully, but these errors were encountered: