Re: Unicode support for the MS Windows clipboard

[Eli Zaretskii]

> From: Benjamin Riefenstahl <address@hidden>
> Date: Thu, 27 May 2004 11:45:42 +0200
> 
> - CF_OEMTEXT - If you want to cut-and-paste line drawing characters
>   between Emacs and other console apps on 9x/Me this would be the type
>   to use.

Doesn't Unicode support line-drawing characters?

> CF_UNICODETEXT is probably marshalled fine, but is it also
> automatically converted?  I.e. will any non-Unicode application be
> able to retrieve the CF_TEXT format that it is entitled to expect,
> when we just post CF_UNICODETEXT?  And the other way around?

Sorry, I don't know the answers to these questions.  We will have to
test that, or ask experts, or google for the info.

> Even if not we could probably try a scheme similar to what you
> outlined above:
> 
> - Receiving:  First try CF_UNICODETEXT.  If CF_UNICODETEXT doesn't
>   exist, try CF_TEXT. 
> 
> - Posting: Post CF_UNICODETEXT.  Test if CF_TEXT is there now.  If
>   CF_TEXT is not automatically provided by Windows, post CF_TEXT
>   ourself in additiona to CF_UNICODETEXT.  Note that this last
>   situation would triple the amount of memory required.

I'd say that for posting, we should try to use selection-coding-system
first, if it makes sense (for some definition of ``make sense'' that
we will have to come up with).  Especially, if selection-coding-system
is the same as the system codepage, we should use CF_TEXT, as that
will, AFAIK, allow more (older) applications to be able to paste.

For receiving, I think the logic you suggest is okay, but we probably
should leave some provision to force Emacs to use CF_TEXT/CF_OEMTEXT
and a specific encoding, for borderline cases that we will never be
able to forsee.

> Anyway, what happens to the MULE problem in this unified scenario?  Do
> all problems go away with unify-8859-on-{de,en}coding?

They should, I think, but only time and experience will tell.  That's
why an option to force Emacs to use CF_TEXT on receive might come in
handy.

> >> - Drop optimizations for ASCII-only text.
> 
> > Is that optimization indeed an optimization?
> 
> It was obviously intented as such, but it may just have been a remnant
> of the code that was there before the introduction of the
> {en,de}coding via coding systems into that module.

I think it's there because the original code written for X had it, and
the Windows port simply copied it (as did the DOS port, see
w16select.c).

Decoding obviously slows down things, but, as Stefan pointed out, the
slow-down could well be below the noise level.

> I will build a version without my patch and test it.

Thanks.