bug#7934: 24.0.50; Nextstep: Can't copy and paste null characters

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Fixed in trunk.

Thanks, Jan.  But I wonder why this bug manifested itself in the "C-k
C-y" case, which I thought would not fetch the selection from the OS but
would short-circuit it and take it directly from the kill-ring (which
has the advantage of preserving the unibyte/multibyte distinction, the
text-properties, ...).


        Stefan


> Harald Hanche-Olsen skrev 2011-01-28 23.41:
>> Starting with .../Emacs.app/Contents/MacOS/Emacs -Q:
>> Type these characters in the *scratch* buffer:
>> abc C-q C-space def
>> so you now have a line looking like
>> abc^@def
>> with the ^@ representing a null character.
>> Now type the characters C-a C-k C-y
>> which should kill the line and then yank it back.
>> 
>> Expected result: The line is unchanged.
>> Actual result: Only the letters abc are yanked back.
>> The null character and the following characters are lost.
>> 
>> (I discovered this when I found myself unable to copy the debugger
>> buffer, which happened to contain bytecode snippets which had null
>> characters in them.)
>> 
>> In GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.5.0, NS apple-appkit-1038.35)
>> of 2011-01-21 on mack
>> Windowing system distributor `Apple', version 10.3.1038
>> configured using `configure  '--with-ns''
>> 
>> Important settings:
>> value of $LC_ALL: nil
>> value of $LC_COLLATE: nil
>> value of $LC_CTYPE: en_US.UTF-8
>> value of $LC_MESSAGES: nil
>> value of $LC_MONETARY: nil
>> value of $LC_NUMERIC: nil
>> value of $LC_TIME: nil
>> value of $LANG: nil
>> value of $XMODIFIERS: nil
>> locale-coding-system: utf-8-unix
>> default enable-multibyte-characters: t
>> 
>> - Harald
>> 
>>