On 2023-02-20, Bruno Barbier wrote:
> Jens Lechtenboerger writes:
>
>> On 2023-02-20, Bruno Barbier wrote:
>>
>> However, if I use insert-file-contents-literally with a unicode
>> file, I do *not* have to set the coding-system-for-write. This just
>> works:
>>
>>(with-temp-buffer
>>
Jens Lechtenboerger writes:
> On 2023-02-20, Bruno Barbier wrote:
>
> However, if I use insert-file-contents-literally with a unicode
> file, I do *not* have to set the coding-system-for-write. This just
> works:
>
>(with-temp-buffer
> (insert-file-contents-literally
On 2023-02-20, Bruno Barbier wrote:
> If you're always using utf-8, here is a way to force it so that
> secure-hash can compute the hash. This should work:
>
>(with-temp-buffer
> (let ((coding-system-for-write 'utf-8))
> (insert "Lechtenb\303\266rger")
> (secure-hash
Jens Lechtenboerger writes:
> On 2023-02-17, Bruno Barbier wrote:
>
>> Here is a way to reproduce that doesn't use org, in case it might help
>> to manully fix your encoding issue:
>>
>>(with-temp-buffer
>> (insert "Lechtenb\303\266rger")
>> (let ((buffer-file-name
On 2023-02-17, Ihor Radchenko wrote:
> Jens Lechtenboerger writes:
>> Also, when I call secure-hash on the literal buffer-string, no
>> problem arises.
>
> Org is calling secure-hash on buffer. Calling on buffer-string would
> require unnecessary memory allocation to create the string.
I can
On 2023-02-17, Bruno Barbier wrote:
> Here is a way to reproduce that doesn't use org, in case it might help
> to manully fix your encoding issue:
>
>(with-temp-buffer
> (insert "Lechtenb\303\266rger")
> (let ((buffer-file-name (make-temp-file "mailtest")))
>
Jens Lechtenboerger writes:
> I was afraid you would say so. To me, this is a breaking change.
It is not a breaking change. It is Org's change revealing issues with
your files. If you need to edit or act upon that part of the file, you
could see the same problem.
> Also, when I call
Jens Lechtenboerger writes:
> So, maybe my question is: Must text be decoded for Org mode from now on?
Yes. Since forever. Emacs must know how to read/write from/to files and
what text to display to you. Org is just relying on Emacs for that part.
Bruno
Jens Lechtenboerger writes:
> On 2023-02-17, Ihor Radchenko wrote:
>
>> Jens Lechtenboerger writes:
>>
>
>> Not a bug. You need to fix your files with improper encoding.
>
> The file has the proper encoding. I insert literally on purpose as
> stated above.
IIUC, the file has the proper
On 2023-02-17, Ihor Radchenko wrote:
> Jens Lechtenboerger writes:
>
>> With Org 9.6.1 from Emacs master, I get the following warning, and I
>> am asked to select a coding system:
>>
>>> These default coding systems were tried to encode the following
>>> problematic characters in the buffer ‘
Jens Lechtenboerger writes:
> With Org 9.6.1 from Emacs master, I get the following warning, and I
> am asked to select a coding system:
>
>> These default coding systems were tried to encode the following
>> problematic characters in the buffer ‘ *temp*’:
>> ...
>
> With previous Org versions,
Hi Bruno,
On 2023-02-17, Bruno Barbier wrote:
> Hi Jens,
>
> Jens Lechtenboerger writes:
>
>> ...
>> Note that I insert contents literally because I do not want
>> ‘find-file-hook’, automatic uncompression, etc. (which are avoided
>> according to the doc string of
Hi Jens,
Jens Lechtenboerger writes:
> ...
> Note that I insert contents literally because I do not want
> ‘find-file-hook’, automatic uncompression, etc. (which are avoided
> according to the doc string of insert-file-contents-literally).
>
> Could the old behavior be restored?
By using
Hi there,
consider this piece code, where unicode-file.org contains umlauts
(say, just the word “Lechtenbörger”):
(org-export-string-as
(with-temp-buffer
(insert-file-contents-literally "unicode-file.org")
(buffer-string))
'html t)
With Org 9.6.1 from Emacs master, I get the following
14 matches
Mail list logo
