Re: Unicode support for the MS Windows clipboard

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

Hi Jason,


Jason Rumney <jasonr@gnu.org> writes:
> it seems that the user must take care to set selection-coding-system
> appropriately for w32-clipboard-type.

Right.  As I said the code is for experimentation right now.

> If that is the case, it might be better to get rid of
> w32-clipboard-type as a user variable, and determine the type
> automatically from selection-coding-system instead. cp<900 should
> map to OEM, utf16 to unicode, and others to ANSI.

Can we just assume this?  Does "cp<900" really garantee OEM?  How do
we know that some exotic private trick coding system isn't usefull for
CF_UNICODETEXT, or for CF_OEMTEXT, or do we just ignore that
possibility?  (Which is fine by me, don't get me wrong, users have the
source after all.)

> Also, we should set (and read) CF_LOCALE when we are using CF_TEXT,
> to indicate the coding we have used.

I'll have to look that up, I'm not familiar with CF_LOCALE.

> When reading from the clipboard, if CF_UNICODE is present, it might
> be better to use that (ignoring selection-coding-system).

Could we get into trouble with the MULE problem here?  Or does
unify-8859-on-{en,de}coding solve this for all cases?

> On the other hand, some Chinese characters are still not covered by
> Emacs' unicode support (even with utf-translate-cjk-mode), [...]
> Big5 is definitely not entirely covered).

If those characters are not supported by Unicode, how does Windows
support them, which is based on Unicode after all?  Does it support
them at all?  Or does it use the private characters for this?


Thanks,
benny


PS: The default for selection-coding-system should be cpXXXX-dos, not
just cpXXXX.  Otherwise I get <LF> as line ends instead of <CR><LF>
when I copy non-ASCII text.  Which than doesn't work well with
Notepad, of course.