GNU bug report logs - #7934
24.0.50; Nextstep: Can't copy and paste null characters

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7934 in the body.
You can then email your comments to 7934 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Nextstep: Can't copy and paste null characters
Date: Fri, 28 Jan 2011 23:41:08 +0100 (CET)

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

Message #10 received at 7934-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
Cc: 7934-done <at> debbugs.gnu.org
Subject: Re: bug#7934: 24.0.50; Nextstep: Can't copy and paste null characters
Date: Sat, 29 Jan 2011 12:32:26 +0100

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

Message #13 received at 7934 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 7934 <at> debbugs.gnu.org
Cc: jan.h.d <at> swipnet.se
Subject: Re: bug#7934: 24.0.50; Nextstep: Can't copy and paste null characters
Date: Sat, 29 Jan 2011 10:53:26 -0500

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

Message #16 received at 7934 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7934 <at> debbugs.gnu.org
Subject: Re: bug#7934: 24.0.50; Nextstep: Can't copy and paste null characters
Date: Sat, 29 Jan 2011 17:56:52 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.