Re: Unicode support for the MS Windows clipboard

[Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>]

Hi Eli,


>> From: Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>
>> - Introduce a new variable `w32-clipboard-type'

"Eli Zaretskii" <eliz@gnu.org> writes:
> Couldn't this be done without introducing Windows-specific options?

I'd certainly love to.  In general all three modes have their use:

- CF_TEXT - This is obviously the fallback. 

- CF_UNICODETEXT - The most capable choice on NT/W2K/XP.  According to
  MSDN not supported on 9x/Me.

- 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.

  You could consider this scenario too exotic, so that we could drop
  it.  OTOH I know of at least one user that is actually using and
  maintaining files with line drawing characters in Emacs.

> AFAIK, the logic employed by Windows when it encodes clipboard text
> is quite simple, something like: if it cannot be encoded with the
> system codepage, use Unicode.  Why cannot Emacs simply follow this
> logic?

Conceptually, Windows doesn't encode, it just marshals memory blocks.

Windows *will* automatically generate any additional supported text
type from whatever an application provides, so that an application
only needs to know one of the three text types.  In this context at
least, 9x/Me only supports CF_TEXT and CF_OEMTEXT while Windows
NT/W2K/XP also supports CF_UNICODETEXT (or so MSDN says).

I don't have a 9x machine ready here at the moment, but I will
probably install one on the weekend for testing of other things
anyway.

> Also, AFAIK CF_UNICODETEXT _can_ be used on Windows 9x, as any
> program like clipbrd.exe or ClipConvert will show you.

9x/Me is explicitly documented on MSDN not to support that.  Being
that - from Windows' POV - we are just talking about memory blocks,
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?

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.


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


>> - 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 will build a
version without my patch and test it.


Thanks for your input,
benny