GNU bug report logs - #45
23.0.60; Can't paste from files with .arc extensions

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 45 in the body.
You can then email your comments to 45 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brian Adkins <info <at> lojic.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Can't paste from files with .arc extensions
Date: Sat, 08 Mar 2008 19:14:27 -0500

I discovered that I could not select text with the mouse and paste via 
middle-button click into a non-emacs window when the file in question 
had a .arc extension. Paul Graham's new Arc language uses .arc as an 
extension and this extension is associated with no-conversion in the 
auto-coding-alist variable as follows:

auto-coding-alist is a variable defined in `mule.el'.
Its value is
(("\\.\\(arc\\|zip\\|lzh\\|lha\\|zoo\\|[jew]ar\\|xpi\\|exe\\|rar\\|ARC\\|ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|EXE\\|RAR\\)\\'" 
. no-conversion)
 ("\\.\\(sx[dmicw]\\|odt\\|tar\\|tgz\\)\\'" . no-conversion)
 ("\\.\\(gz\\|Z\\|bz\\|bz2\\|gpg\\)\\'" . no-conversion)
 ("\\.\\(jpe?g\\|png\\|gif\\|tiff?\\|p[bpgn]m\\)\\'" . no-conversion)
 ("\\.pdf\\'" . no-conversion)
 ("/#[^/]+#\\'" . emacs-mule))

I am able to fix the problem by removing arc from the auto-coding-alist, 
but someone on gnu.emacs.help suggested I should file a bug report 
regarding this behavior.

Thanks,
Brian Adkins


In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.12.0)
 of 2008-02-06 on airstream
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--enable-font-backend' '--with-gif=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Message #10 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Magnus Henoch <mange <at> freemail.hu>
To: 45 <at> debbugs.gnu.org
Subject: Could it be single-byteness?
Date: Wed, 12 Mar 2008 00:04:20 +0100

I recently encountered similar behaviour in completely different
circumstances, but it struck me - is this bug caused by the
single-byteness of the buffer?

To reproduce:

1. Create a new buffer.
2. Make it single-byte with M-x toggle-enable-multibyte-characters
3. Write something and copy it with M-x clipboard-kill-ring-save
4. Try to paste it into Firefox with C-v

For me, nothing happens in step 4.

The same thing happpens with Brian's mouse-based recipe.  Reenabling
multibyte characters makes it work again.

Magnus

Message #15 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Magnus Henoch <mange <at> freemail.hu>
To: 45 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Hm...
Date: Wed, 12 Mar 2008 00:25:19 +0100

clone 45 -1
retitle 45 Can't paste from unibyte buffers
retitle -1 Files with .arc extensions are treated as archives, not Arc source code
thanks

That was what I _really_ meant with my incoherent rambling...

Message #22 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>, 45 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Cc: Magnus Henoch <mange <at> freemail.hu>, Brian Adkins <info <at> lojic.com>
Subject: Re: 3.0.60; Can't paste from files with .arc extensions
Date: Mon, 07 Apr 2008 23:26:37 -0400

Magnus Henoch <mange <at> freemail.hu> wrote:

> 1. Create a new buffer.
> 2. Make it single-byte with M-x toggle-enable-multibyte-characters
> 3. Write something and copy it with M-x clipboard-kill-ring-save
> 4. Try to paste it into Firefox with C-v
>
> For me, nothing happens in step 4.

This bug arises from the following checkin, introduced to the unicode-2
branch on Nov 18 and subsequently merged to the trunk:

2008-02-01  Kenichi Handa  <handa <at> m17n.org>

	* select.el (selection-coding-system, next-selection-coding-system):
	Move declarations from xselect.c.
	(x-get-selection): Decode by selection-coding-system if it is non-nil.
	If it is nil, decode by a proper coding system.  Handle C_STRING.
	(ccl-check-utf-8, string-utf-8-p): Delete them.
	(xselect-convert-to-string): Fix determining data-type in the case
	that TEXT is requested.  Don't use selection-coding-system if it's
	not proper for the data-type.

The problem seems to go away with the following patch to
xselect-convert-to-string, which changes the coding for unibyte string
from C_STRING back to STRING, the value prior to the Nov 18 change.  But
I am unfamiliar with this part of the code.  Could someone who knows
what is going on give an opinion (Handa-san)?


*** trunk/lisp/select.el.~1.39.~	2008-02-08 15:16:35.000000000 -0500
--- trunk/lisp/select.el	2008-04-07 23:15:34.000000000 -0400
***************
*** 243,249 ****
  	  (remove-text-properties 0 (length str) '(composition nil) str)
  	  (if (not (multibyte-string-p str))
  	      ;; Don't have to encode unibyte string.
! 	      (setq type 'C_STRING)
  	    (if (eq type 'TEXT)
  		;; TEXT is a polimorphic target.  We must select the
  		;; actual type from `UTF8_STRING', `COMPOUND_TEXT',
--- 243,249 ----
  	  (remove-text-properties 0 (length str) '(composition nil) str)
  	  (if (not (multibyte-string-p str))
  	      ;; Don't have to encode unibyte string.
! 	      (setq type 'STRING)
  	    (if (eq type 'TEXT)
  		;; TEXT is a polimorphic target.  We must select the
  		;; actual type from `UTF8_STRING', `COMPOUND_TEXT',

Message #27 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 45 <at> debbugs.gnu.org, emacs-devel <at> gnu.org, info <at> lojic.com,
        mange <at> freemail.hu
Subject: Re: 3.0.60; Can't paste from files with .arc extensions
Date: Tue, 08 Apr 2008 15:37:13 +0900

In article <87hcedrpqq.fsf <at> stupidchicken.com>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> The problem seems to go away with the following patch to
> xselect-convert-to-string, which changes the coding for unibyte string
> from C_STRING back to STRING, the value prior to the Nov 18 change.  But
> I am unfamiliar with this part of the code.  Could someone who knows
> what is going on give an opinion (Handa-san)?

The contents of unibyte buffer is typically binary data, and
according to X's "Inter-Client Communication Conventions
Manual", "STRING as a type or a target specifies the ISO
Latin-1 char- acter set ...".  So I chose C_STRING which is
defined as:
------------------------------------------------------------
There are some text objects where the source or intended
user, as the case may be, does not have a specific character
set for the text, but instead merely requires a zero-termi-
nated sequence of bytes with no other restriction; no ele-
ment of the selection mechanism may assume that any byte
value is forbidden or that any two differing sequences are
equivalent.  For these objects, the type C_STRING should be
used.
------------------------------------------------------------

Why do you have to use a unibyte buffer?

---
Kenichi Handa
handa <at> ni.aist.go.jp

Message #32 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 45 <at> debbugs.gnu.org
Subject: Re: 23.0.60; Can't paste from files with .arc extensions
Date: Wed, 09 Apr 2008 22:39:33 -0400

severity 45 wontfix

OK, we'll leave the matter as it stands.  Tagging as wontfix.

Message #37 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 45 <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Thu, 10 Apr 2008 14:26:53 -0400

> OK, we'll leave the matter as it stands.  Tagging as wontfix.

Not sure if I agree with this.
Which applications accept the C_STRING?
I mean, if Firefox doesn't accept it, it's likely many others refuse it
as well.  Why not treat the binary as Latin-1 and sent it as STRING?

Are there cases where it's known to cause problems?


        Stefan

Message #42 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
        Kenichi Handa  <handa <at> ni.aist.go.jp>
Cc: 45 <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Thu, 10 Apr 2008 16:03:19 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> OK, we'll leave the matter as it stands.  Tagging as wontfix.
>
> Not sure if I agree with this.
> Which applications accept the C_STRING?
> I mean, if Firefox doesn't accept it, it's likely many others refuse it
> as well.  Why not treat the binary as Latin-1 and sent it as STRING?
>
> Are there cases where it's known to cause problems?

Apart from Firefox, GTK applications don't accept C_STRING, while xterm
does.

IIUC, Handa's argument is that a unibyte buffer typically represents
binary data, so it's more correct to tag it as C_STRING.  If other
applications choose to refuse C_STRING because they don't think it
generally maps to Latin-1 output, that's their choice.

Message #47 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Kenichi Handa <handa <at> ni.aist.go.jp>, 45 <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Thu, 10 Apr 2008 17:19:14 -0400

>>> OK, we'll leave the matter as it stands.  Tagging as wontfix.
>> 
>> Not sure if I agree with this.
>> Which applications accept the C_STRING?
>> I mean, if Firefox doesn't accept it, it's likely many others refuse it
>> as well.  Why not treat the binary as Latin-1 and sent it as STRING?
>> 
>> Are there cases where it's known to cause problems?

> Apart from Firefox, GTK applications don't accept C_STRING, while xterm
> does.

> IIUC, Handa's argument is that a unibyte buffer typically represents
> binary data, so it's more correct to tag it as C_STRING.  If other
> applications choose to refuse C_STRING because they don't think it
> generally maps to Latin-1 output, that's their choice.

I understand that.  It's the theory.  The practice is that it implies
that cut&paste fails between Emacs and Gtk applications in some cases.
Maybe it's OK.  But it's a definite downside.

What would be the downside *in practice* of labelling our binary data as
STRING (i.e. latin-1)?


        Stefan

Message #52 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: monnier <at> iro.umontreal.ca, 45 <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Fri, 11 Apr 2008 12:57:13 +0900

In article <87myo1eauw.fsf <at> stupidchicken.com>, Chong Yidong <cyd <at> stupidchicken.com> writes:
> Apart from Firefox, GTK applications don't accept C_STRING, while xterm
> does.

> IIUC, Handa's argument is that a unibyte buffer typically represents
> binary data, so it's more correct to tag it as C_STRING.  If other
> applications choose to refuse C_STRING because they don't think it
> generally maps to Latin-1 output, that's their choice.

I think the attached patch will solve the problem.  It does
this:

If TEXT is requested, selecte C_STRING for unibyte
buffer/string.  If an application doesn't like C_STRING, it
will request again with STRING or COMPOUND_TEXT.  In such a
case, follow what requested.

---
Kenichi Handa
handa <at> ni.aist.go.jp


*** select.el.~1.39.~	2008-02-09 05:16:35.000000000 +0900
--- select.el	2008-04-11 12:48:19.000000000 +0900
***************
*** 241,253 ****
  	(let ((inhibit-read-only t))
  	  ;; Suppress producing escape sequences for compositions.
  	  (remove-text-properties 0 (length str) '(composition nil) str)
! 	  (if (not (multibyte-string-p str))
! 	      ;; Don't have to encode unibyte string.
! 	      (setq type 'C_STRING)
! 	    (if (eq type 'TEXT)
! 		;; TEXT is a polimorphic target.  We must select the
! 		;; actual type from `UTF8_STRING', `COMPOUND_TEXT',
! 		;; `STRING', and `C_STRING'.
  		(let (non-latin-1 non-unicode eight-bit)
  		  (mapc #'(lambda (x)
  			    (if (>= x #x100)
--- 241,252 ----
  	(let ((inhibit-read-only t))
  	  ;; Suppress producing escape sequences for compositions.
  	  (remove-text-properties 0 (length str) '(composition nil) str)
! 	  (if (eq type 'TEXT)
! 	      ;; TEXT is a polimorphic target.  We must select the
! 	      ;; actual type from `UTF8_STRING', `COMPOUND_TEXT',
! 	      ;; `STRING', and `C_STRING'.
! 	      (if (not (multibyte-string-p str))
! 		  (setq type 'C_STRING)
  		(let (non-latin-1 non-unicode eight-bit)
  		  (mapc #'(lambda (x)
  			    (if (>= x #x100)
***************
*** 259,290 ****
  			str)
  		  (setq type (if non-unicode 'COMPOUND_TEXT
  			       (if non-latin-1 'UTF8_STRING
! 				 (if eight-bit 'C_STRING 'STRING))))))
! 	    (cond
! 	     ((eq type 'UTF8_STRING)
! 	      (if (or (not coding)
! 		      (not (eq (coding-system-type coding) 'utf-8)))
! 		  (setq coding 'utf-8))
! 	      (setq str (encode-coding-string str coding)))
! 
! 	     ((eq type 'STRING)
! 	      (if (or (not coding)
! 		      (not (eq (coding-system-type coding) 'charset)))
! 		  (setq coding 'iso-8859-1))
! 	      (setq str (encode-coding-string str coding)))
! 
! 	     ((eq type 'COMPOUND_TEXT)
! 	      (if (or (not coding)
! 		      (not (eq (coding-system-type coding) 'iso-2022)))
! 		  (setq coding 'compound-text-with-extensions))
! 	      (setq str (encode-coding-string str coding)))
! 
! 	     ((eq type 'C_STRING)
! 	      (setq str (string-make-unibyte str)))
! 
! 	     (t
! 	      (error "Unknow selection type: %S" type))
! 	     ))))
  
        (setq next-selection-coding-system nil)
        (cons type str))))
--- 258,289 ----
  			str)
  		  (setq type (if non-unicode 'COMPOUND_TEXT
  			       (if non-latin-1 'UTF8_STRING
! 				 (if eight-bit 'C_STRING 'STRING)))))))
! 	  (cond
! 	   ((eq type 'UTF8_STRING)
! 	    (if (or (not coding)
! 		    (not (eq (coding-system-type coding) 'utf-8)))
! 		(setq coding 'utf-8))
! 	    (setq str (encode-coding-string str coding)))
! 
! 	   ((eq type 'STRING)
! 	    (if (or (not coding)
! 		    (not (eq (coding-system-type coding) 'charset)))
! 		(setq coding 'iso-8859-1))
! 	    (setq str (encode-coding-string str coding)))
! 
! 	   ((eq type 'COMPOUND_TEXT)
! 	    (if (or (not coding)
! 		    (not (eq (coding-system-type coding) 'iso-2022)))
! 		(setq coding 'compound-text-with-extensions))
! 	    (setq str (encode-coding-string str coding)))
! 
! 	   ((eq type 'C_STRING)
! 	    (setq str (string-make-unibyte str)))
! 
! 	   (t
! 	    (error "Unknow selection type: %S" type))
! 	   )))
  
        (setq next-selection-coding-system nil)
        (cons type str))))

Message #57 received at 45 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 45 <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Tue, 15 Apr 2008 09:29:20 -0400

> I think the attached patch will solve the problem.  It does
> this:

> If TEXT is requested, selecte C_STRING for unibyte
> buffer/string.  If an application doesn't like C_STRING, it
> will request again with STRING or COMPOUND_TEXT.  In such a
> case, follow what requested.

Looks good.  Please install it (and mark this bug as closed).

Thanks!

Message #62 received at 45-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: monnier <at> iro.umontreal.ca, 45-done <at> debbugs.gnu.org
Subject: Re: bug#45: 23.0.60; Can't paste from files with .arc extensions
Date: Sun, 20 Apr 2008 22:02:34 -0400

> I think the attached patch will solve the problem.  It does
> this:
>
> If TEXT is requested, selecte C_STRING for unibyte
> buffer/string.  If an application doesn't like C_STRING, it
> will request again with STRING or COMPOUND_TEXT.  In such a
> case, follow what requested.

I checked in the patch.  Thanks.

Previous Next

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