Re: [PATCH] Add yank-media handler for LibreOffice Calc tables

[Visuwesh <visuweshm@gmail.com>]

[செவ்வாய் அக்டோபர் 15, 2024] Ihor Radchenko wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>>> Something is off with encoding.
>>
>> I cannot reproduce it on my end.  I tried with different documents and
>> document types (Excel and LO format).  Would it be possible to send the
>> faulty file?
>
> Here is the recipe
> 1. make repro (I tried with the latest Emacs master and with Emacs 29)
> 2. Open test.odt (attached)
> 3. M-x org-mode
> 4. Copy the non-empty cell area
> 5. M-x yank-media <RET> app<TAB> <RET>
> 6. Observe encoding problems

Thanks for the reproducer.  I think this might be locale-dependent.  I
fail to reproduce on my end with the following locale settings:

    LANG=en_GB.UTF-8
    LC_COLLAGE=ta_IN.UTF-8
    LC_MONETARY=ta_IN.UTF-8
    LC_NUMERIC=ta_IN.UTF-8

    locale-coding-system = 'utf-8-unix

I have no idea how to deal with locale issues like this unfortunately.

>>>> +    (insert data)
>>>> +    ;; LibreOffice source code defines
>>>> +    ;; 'application/x-libreoffice-tsvc' as Text TSV-Calc so it should
>>>> +    ;; be safe to handle this as TSV always.
>>>> +    (org-table-convert-region beg (point) '(16))))
>>>
>>> What if the point is in the middle of something else?
>>> For example, in the middle of another table.
>>> Then, conversion may yield wild outcomes.
>>> Maybe it is safer to convert region in a temporary buffer and
>>> insert the final result into the Org document being edited.
>>
>> Even if we do the processing in a temporary buffer, we would still end
>> up inserting the table after point.  I say we leave it to the user to be
>> prudent and not call yank-media when in the middle of a table or
>> somesuch.  We do not do any special handling in other handlers, so why
>> do it here?
>
> Consider the following example:
>
> * Heading <point>
>
> M-x yank-media ... will slurp the heading
>
> | * Heading a | b | c |
>
> In contrast, the existing handlers will only insert some text at point,
> never touching the text around.

Would it be sufficient to unconditionally insert a newline after point?
Maybe even after going to end of current element (if that can be done).