Re: Unicode support for the MS Windows clipboard [new patch]

[Benjamin Riefenstahl]

Hi Eli, Jason,


Sorry for taking so long to follow up. 

"Eli Zaretskii" <address@hidden> writes:
> I don't think the documentation of this should go into msdog.texi.
> That section is for the MS-DOS port, and in the printed version it
> goes into an appendix.  Windows users will not expect to find it
> there.

Well, as my defense, I seem to remember that folks on this list were
asked to look at the MS-DOS sections of the manual for
Windows-specific questions.  Also the index item "Windows clipboard
support" actually points to msdog.texi.  Maybe this should better be
"Windows clipboard support on MS-DOS", than.

> I think we should leave msdog.texi alone and instead put the
> Windows-related text into mule.texi (since the only different aspect
> is the encoding/decoding issue).

While set-selection-coding-system is discussed there shortly, neither
the default value nor any reason to customize it is actually
mentioned.  There may not be much reason to discuss actual
customization options for X11 but there is even less reason on
Windows.  So maybe we don't need any additional documentation here at
all?


I notice that I have left a few other questions un-answered before:


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

"Eli Zaretskii" <address@hidden> writes:
> Doesn't Unicode support line-drawing characters?

Yes, but lots of applications don't support Unicode and 9x/Me doesn't
provide automated conversion to the 8-bit encodings.


Jason Rumney <address@hidden> writes:
> >>[Setting the default to Unicode on 9x/Me] There is no harm in doing
> >>it on 9x if we are also setting CF_TEXT manually.

Not sure what you mean with "setting CF_TEXT manually"?  If you mean
directly, non-delayed, the code doesn't usually do that (see below for
discussion of the one exception).

I think I have lost the context of that discussion a bit here.  I'll
just take the opportunity to discuss the actual behaviour of the code
with a bit more detail to clarify possible misunderstandings.

> Benjamin Riefenstahl wrote:
> >Neither the current default setting on 9x (matching cpXXXX), nor
> >utf-16le have any impact on normal operations, because they just
> >re-state the defaults, and they only apply to the respective
> >clipboard type.
> 
> I'm confused. If the default setting on 9x is cpXXXX, then
> CF_UNICODETEXT is not offered to the clipboard as an available
> format, or read from the clipboard, right?

No.  I implemented delayed rendering such that *all* possible formats
are always offered for rendering (CF_TEXT, CF_UNICODETEXT and
CF_OEMTEXT).  The pasting application gets to choose what it actually
prefers, and only when a paste is actually done, the data is
converted.

The customization of {next-}selection-coding-system only affects the
conversion of the one format of the three that matches the coding
system in question.  It doesn't affect which formats are offered.
Formats that do not match the current setting of the
{next-}selection-coding-system will use the Windows defaults.

The reason for that was the requirement not to introduce additional
config items.  Also, I imagine, that specific problems would be
limited to one of the three formats, actually I expect them only in
CF_TEXT or CF_OEMTEXT.  This would depend on the application that
Emacs is communicating with and its preferred format.

Implementing to offer all three formats was trivial once all cases
were implemented anyway so I didn't see a reason to limit this.

> In that case, Emacs is unable to transfer multilingual text between
> other Unicode aware programs such as MS Office, IE and
> Mozilla. Using utf-16le by default would allow this.

But if we *only* supported Unicode, Emacs would not be able to
transfer to non-Unicode applications at all on 9x/Me.


To expand on the "manual" setting remark above: There is only one
place where the system sets the clipboard directly, non-delayed.  That
is during Emacs exit (this may actually be were the discussion above
originated).  Naturally we can't use delayed rendering for whatever is
on the clipboard at this point any more, so I set the format that
matches the current selection-coding-system.  If that is
CF_UNICODETEXT, I also set CF_TEXT.  This is intended for 9x/Me, but
to keep the behaviour consistent, I also do this on NT-based systems.

How does the X11 delayed rendering code handle shut-down?


Jason Rumney <address@hidden> writes:
> This might all become much simpler once the unicode branch is merged
> anyway.

You mention that hope in other posts, too.  I don't believe the
Unicode branch will make things any easier for this code.

Unicode on the inside of Emacs will at the most change the code to
actually do the encoding conversion, i.e. the small bits where the
coding-system is setup for encode_coding() and decode_coding().  But
the bulk of the code in w32select.c is about handling the Windows side
of things, and that will not change, unless the we were to drop
requirements, like e.g. 9x/Me support.


benny