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

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

[Harald Hanche-Olsen]

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

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

[Jan Djärv]

Fixed in trunk.

Thanks,

	Jan D.


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

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

[Stefan Monnier]

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

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

[Jan Djärv]

Stefan Monnier skrev 2011-01-29 16.53:
>> 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, ...).
>

Maybe it should, but it doesn't.  Here is a lisp backtrace after doing C-y:

"ns-get-cut-buffer-internal" (0x5fbfd598)
"ns-get-pasteboard" (0x5fbfdaa8)
"x-selection-value" (0x5fbfdfc8)
"current-kill" (0x5fbfe4f0)
"yank" (0x5fbfea58)

So the faulty logic (if any) must be as early as current-kill, I guess?

	Jan D.