Sorry for the late reply.  I was busy with uni.

[திங்கள் அக்டோபர் 21, 2024] Visuwesh wrote:

> [திங்கள் அக்டோபர் 21, 2024] Rens Oliemans wrote:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>>> If possible, could you please try LibreOffice 7.6.4? The version Ihor
>>> has installed in his system.  There is an AppImage available for you to
>>> try.
>>
>> Yep, on 7.6.4 the problem occurs.
>>
>>     $ ./LibreOffice-7.6.4.1.basic-x86_64.AppImage --version
>>     LibreOffice 7.6.4.1 e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
>>
>>     Debugger entered--entering a function:
>>     * org--libreoffice-table-handler(application/x-libreoffice-tsvc #("f\0o\0o\0\11\0b\0a\0r\0\11\0\n\0001\0\11\0002\0\11\0003\0\n\0" 0 30 (foreign-selection STRING)))
>>       yank-media()
>>
>> , resulting in
>>
>>     | f\0o\0o\0 | \0b\0a\0r\0 | \0    |
>>     | \01\0     | \02\0       | \03\0 |
>>     | \0        |             |       |
>>
>> To narrow it down a bit more: the problem exists in 7.6.5.2, and does not exist in the
>> following release, 7.6.6.3.
>
> Thank you!  So it is most likely not locale related---a major headache
> saved.  I will look into this soon (cannot promise anything this week
> unfortunately).

For reasons that escape me completely, I did not see null bytes in the
selection in

    % ./LibreOffice-7.6.4.1.standard.help-x86_64.AppImage --version
    LibreOffice 7.6.4.1 e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1

But considering that the chances of having null bytes in documents are
very low, I decided to bruteforce strip them.

[சனி அக்டோபர் 19, 2024] Visuwesh wrote:

> [சனி அக்டோபர் 19, 2024] Ihor Radchenko wrote:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>>>> Also, do note that any text exceeding
>>>> `org-table-convert-region-max-lines' will lead to
>>>> `org-table-convert-region' throwing an error.
>>>
>>> Catching that and messaging the user should be sufficient?
>>
>> Maybe. Or we may catch and ask user to lift the restriction temporarily.
>> Something like:
>>
>> Inserting large table with more than `org-table-convert-region-max-lines' <number>. Continue? (yes/no)
>
> Ah, something like what Calc does.  Yes, I will go with this approach.
> Thanks for the suggestion.

I have now done this in the attached patch.  I use a temporary buffer to
convert the table, and also decode it as per buffer-file-coding-system
of the Org buffer as I could not tell whether LibreOffice always uses
UTF-8 or not.  I believe buffer-file-coding-system should be utf-8 on
most systems so it should be a safe choice.