Can't paste from files with .arc extension
Brian Adkins
select portions of a file with the mouse and paste it in another
window, if the file in question has a .arc extension.
I've been experimenting with Paul Graham's Arc language which as .arc
extensions. I originally thought it might have something to do with
the arc-mode.el major mode file I've been using for Arc code, but I've
turned that off, so the files are loaded in Fundamental mode.
I also thought it could be a file encoding issue, but if I copy the
file to a file with a different extension (.scm for example), I can
open the file and copy/paste with the mouse just fine. If I then copy
the file to a different file with a .arc extension, copy/paste is
broken again.
I can copy/paste within emacs fine, I just can't paste into another
application.
Can anyone think of why emacs might disable pasting to another window
for files with .arc extensions?
Brian Adkins
FYI - I'm using emacs 23 built from source on Ubuntu Linux 7.10
Brian Adkins
Everything works fine when running w/o X via emacs -nw
While experimenting, I received the following error after entering the
following from the command line:
emacs bja.arc
"File mode specification error: (error "Autoloading failed to define
function archive-mode")
Peter Dyballa
Am 07.03.2008 um 15:26 schrieb Brian Adkins:
> "File mode specification error: (error "Autoloading failed to define
> function archive-mode")
You'll need to adjust auto-mode-alist.
--
Greetings
Pete
November, n.:
The eleventh twelfth of a weariness.
– Ambrose Bierce, "The Devil's Dictionary"
Brian Adkins
> Am 07.03.2008 um 15:26 schrieb Brian Adkins:
>
> > "File mode specification error: (error "Autoloading failed to define
> > function archive-mode")
>
> You'll need to adjust auto-mode-alist.
Thanks, but I think the error message is a red herring as far as the
copy/paste problem is concerned. I had turned off the Arc code major
mode to eliminate it as a factor. I just did the following to
eliminate the above error:
(add-to-list 'auto-mode-alist '("\\.arc$" . ruby-mode))
The file loads fine w/o errors now, but I still can't paste into a non-
emacs window. I don't fully understand the X windows copy/paste
mechanism, but I think the source app is involved when pasting into a
destination app, so apparently emacs is doing something different when
the file has a .arc extension regardless of the major mode in effect.
Peter Dyballa
Am 07.03.2008 um 16:32 schrieb Brian Adkins:
> I think the source app is involved when pasting
M-x describe-mode RET RET could reveal something. Also C-u C-x = on
characters.
--
Greetings
Pete
A morning without coffee is like something without something else.
Brian Adkins
> Am 07.03.2008 um 16:32 schrieb Brian Adkins:
>
> > I think the source app is involved when pasting
>
> M-x describe-mode RET RET could reveal something. Also C-u C-x = on
> characters.
I've blown away my .emacs file temporarily for a clean test, and I get
identical results. I'm running "GNU Emacs 23.0.60.2".
The major mode is Fundamental and the results of describe-mode are:
"Enabled minor modes: Auto-Compression Blink-Cursor File-Name-Shadow
Font-Lock Global-Auto-Composition Global-Font-Lock Line-Number
Menu-Bar Mouse-Wheel Tool-Bar Tooltip Transient-Mark"
If I rename the file from temp.arc to temp.txt, the major mode is Text
and the describe-mode command shows:
"Enabled minor modes: Auto-Composition Auto-Compression Blink-Cursor
File-Name-Shadow Font-Lock Global-Auto-Composition Global-Font-Lock
Line-Number Menu-Bar Mouse-Wheel Tool-Bar Tooltip Transient-Mark"
Given that I'm running without a .emacs file, I would think this would
be easy to duplicate. Just load a text file with a .arc extension and
try and select test in emacs and middle-button paste in a non-emacs
window. When I do that, I get nothing.
Brian Adkins
> On Mar 7, 11:05 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
>
> > Am 07.03.2008 um 16:32 schrieb Brian Adkins:
>
> > > I think the source app is involved when pasting
>
> > M-x describe-mode RET RET could reveal something. Also C-u C-x = on
> > characters.
Oh, I also tried C-u C-x = and the results are identical, except
temp.txt shows "There are text properties here:
auto-composed t"
and temp.arc doesn't have that. I don't think the content matters,
because if I simply rename a .arc file to .txt or some other
extension, it works fine. The problem only occurs when the file ends
in .arc
Peter Dyballa
Am 07.03.2008 um 17:18 schrieb Brian Adkins:
> Given that I'm running without a .emacs file, I would think this would
> be easy to duplicate. Just load a text file with a .arc extension and
> try and select test in emacs and middle-button paste in a non-emacs
> window. When I do that, I get nothing.
In that case you might run into an error: auto-mode-alist will have
("\\.\\(arc\\|zip\\|lzh\\|lha\\|zoo\\|[jew]ar\\|xpi\\|rar\\|ARC\\|
ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|RAR\\)\\'" . archive-mode)
Copying a text file to name.arc and opening it in 'emacs -Q' gives me
a Fundamental View and no problems with copy and paste. Problems
start when the "ARC" file contains control characters or characters
that cannot be displayed in the buffer's encoding and therefore are
printed as \<some octal codes>.
Having set LC_CTYPE to <country>_<COUNTRY>.UTF-8 I don't get
autocomposed characters ...
--
Greetings
Pete <\
_\ O _
|o \ _\\_/-\='
_____________(_)|-(_) (_)___________________________________
Brian Adkins
> Am 07.03.2008 um 17:18 schrieb Brian Adkins:
>
> > Given that I'm running without a .emacs file, I would think this would
> > be easy to duplicate. Just load a text file with a .arc extension and
> > try and select test in emacs and middle-button paste in a non-emacs
> > window. When I do that, I get nothing.
>
> In that case you might run into an error: auto-mode-alist will have
>
> ("\\.\\(arc\\|zip\\|lzh\\|lha\\|zoo\\|[jew]ar\\|xpi\\|rar\\|ARC\\|
> ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|RAR\\)\\'" . archive-mode)
I can set the file to whatever mode I want after loading and it
exhibits the same "can't paste to non-emacs window" problem.
> Copying a text file to name.arc and opening it in 'emacs -Q' gives me
> a Fundamental View and no problems with copy and paste. Problems
> start when the "ARC" file contains control characters or characters
> that cannot be displayed in the buffer's encoding and therefore are
> printed as \<some octal codes>.
>
> Having set LC_CTYPE to <country>_<COUNTRY>.UTF-8 I don't get
> autocomposed characters ...
As I mentioned before, I can rename any file to have a .arc extension
and I get this problem, so it's not a character encoding issue.
Just to confirm what you're saying about "no problems", are you:
1) running emacs in X windows as opposed to a terminal window
2) selecting text with the mouse AND
3) middle-button pasting into a *non-emacs* window such as a shell
If so, I'm dumbfounded. When I explained what I was doing clearly,
another person on the Arc forum was able to see the same results with
emacs v23, so it's not unique to my particular environment.
I can copy/paste from/to emacs windows without difficulty, it's only
when selecting and middle-button pasting into a non-emacs window where
the difficulty arises.
Hmm.. I just tried renaming to temp.zip and had the same paste
problem, so the auto-mode-alist does seem related. However, when I re-
add the code I had originally to set the mode properly, I no longer
get the error message, but I still have trouble with pasting outside
of emacs, so it appears either there is something other than the auto-
mode-alist causing the problem, or that adding a valid arc-mode isn't
sufficient and I need to remove the existing entries from the auto-
mode-alist variable. I would think that once a match is found, the
other entries wouldn't be considered, but maybe that's a wrong
assumption.
Brian Adkins
me to auto-coding-alist:
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))
Documentation:
Alist of filename patterns vs corresponding coding systems.
Each element looks like (REGEXP . CODING-SYSTEM).
A file whose name matches REGEXP is decoded by CODING-SYSTEM on
reading.
The settings in this alist take priority over `coding:' tags
in the file (see the function `set-auto-coding')
and the contents of `file-coding-system-alist'.
You can customize this variable.
Brian Adkins
Yep, that did the trick! I clicked on the customize link in the help
(ya gotta love how integrated code, variables, help, etc. is in emacs)
and removed arc from the 'no-conversion' association.
Thanks for your time in pointing me down the right road Peter.
Peter Dyballa
Am 07.03.2008 um 18:40 schrieb Brian Adkins:
> I kept poking around auto-mode-alist and it pointed
> me to auto-coding-alist
Ah! So the contents has an attribute of being binary, unconvertible.
Why can't you use another extension? .bark for example, nothing doggy-
esk, just to remember Carl Barks, who invented most of the
inhabitants of Duckburg ...
--
Greetings
Pete
Wasting time is an important part of living.
Eli Zaretskii
> Date: Fri, 7 Mar 2008 09:43:57 -0800 (PST)
It sounds like you found a bug in Emacs, because pasting into other
applications should not require any changes to `auto-coding-alist'.
Could you please submit a bug report (using "M-x report-emacs-bug") to
emacs...@gnu.org, so that the developers could investigate the
problem and find a solution for it for the upcoming release 22.2 of
Emacs?
In your report, please show the exact sequence of commands, starting
from "emacs -Q", to reproduce the problem.
TIA
Brian Adkins
> > From: Brian Adkins <lojicdot...@gmail.com>
> problem and find a solution for it for the upcoming release 22.2 of
> Emacs?
>
> In your report, please show the exact sequence of commands, starting
> from "emacs -Q", to reproduce the problem.
>
> TIA
I thought that inclusion of the .arc extension in the auto-coding-
alist meant that emacs considered the file to be binary and thus would
not paste contents into another application. Are you saying that the
expected behavior is for emacs to paste anyway?
Eli Zaretskii
> Date: Sat, 8 Mar 2008 07:27:32 -0800 (PST)
>
> I thought that inclusion of the .arc extension in the auto-coding-
> alist meant that emacs considered the file to be binary and thus would
> not paste contents into another application. Are you saying that the
> expected behavior is for emacs to paste anyway?
Yes, I don't see any reason why printable characters from a binary
file could not be pasted into another application. Emacs has a way of
dealing with characters that cannot be safely put into the X selection
(it replaces them with `?'s or some such), if that's what you thought
could prevent copy-paste.
So I encourage you to report this as a bug. Thanks.
Stefan Monnier
> alist meant that emacs considered the file to be binary and thus would
> not paste contents into another application. Are you saying that the
> expected behavior is for emacs to paste anyway?
It should paste something. At least the ascii part of the binary stream
(i.e. the byte codes 0-127) should be copy/pastable.
Stefan
Peter Dyballa
Pasting from GNU Emacs a selection with control characters (for
example from a *Backtrace* buffer that contains parts of an ELC file)
into a Mac OS X application makes 0 bytes appear there. A similiar
behaviour can be observed with vi(m) in an XTerm. Pasting the same
few control characters directly into XTerm can do funny things ... In
the end no resemblance is left.
--
Greetings
Pete
For some reason, this fortune reminds everyone of Marvin Zelkowitz.
Brian Adkins
> > From: Brian Adkins <lojicdot...@gmail.com>
I went ahead and filed the bug report as you suggested in case the
desired behavior is to paste from no-conversion files; however, in my
case, I think the proper thing to do is to remove .arc from the list
since in my case a .arc file is simply a file containing a dialect of
Lisp.
Eli Zaretskii
> Date: Sat, 8 Mar 2008 23:45:46 +0100
> Cc: help-gn...@gnu.org
>
> Pasting from GNU Emacs a selection with control characters (for
> example from a *Backtrace* buffer that contains parts of an ELC file)
> into a Mac OS X application makes 0 bytes appear there. A similiar
> behaviour can be observed with vi(m) in an XTerm. Pasting the same
> few control characters directly into XTerm can do funny things ... In
> the end no resemblance is left.
What about the printable characters? do they get pasted okay? I
thought the OP said nothing is pasted, not even printables.
Eli Zaretskii
> Date: Sat, 8 Mar 2008 16:16:01 -0800 (PST)
>
> I went ahead and filed the bug report as you suggested in case the
> desired behavior is to paste from no-conversion files;
Thank you.
> however, in my
> case, I think the proper thing to do is to remove .arc from the list
> since in my case a .arc file is simply a file containing a dialect of
> Lisp.
That is a different issue: if an .arc file is not an archive, then you
should indeed remove the extension from the list. But it is unrelated
to copy/paste, IMO.
Peter Dyballa
Am 09.03.2008 um 05:15 schrieb Eli Zaretskii:
> What about the printable characters? do they get pasted okay? I
> thought the OP said nothing is pasted, not even printables.
That's the case with a mixture of printable and non-printable
characters (in octal notation): *nothing* gets pasted into a Mac OS X
application, and vi(m) running in XTerm can behave very differently:
nothing is visible (pasted), vim does not respond to any key input,
weird text appears ...
--
Greetings
Pete (:
_ / __ - -
_/ \__/_/ - -
(´`) (´`) - -
`´ `´
Eli Zaretskii
> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Sun, 9 Mar 2008 10:26:40 +0100
>
>
> Am 09.03.2008 um 05:15 schrieb Eli Zaretskii:
>
> > What about the printable characters? do they get pasted okay? I
> > thought the OP said nothing is pasted, not even printables.
>
> That's the case with a mixture of printable and non-printable
> characters (in octal notation): *nothing* gets pasted into a Mac OS X
> application
What if you only mark strictly printable characters? does it work
then?
Peter Dyballa
Am 09.03.2008 um 23:06 schrieb Eli Zaretskii:
>>> What about the printable characters? do they get pasted okay? I
>>> thought the OP said nothing is pasted, not even printables.
>>
>> That's the case with a mixture of printable and non-printable
>> characters (in octal notation): *nothing* gets pasted into a Mac OS X
>> application
>
> What if you only mark strictly printable characters? does it work
> then?
These can easily be copied. This way I could cite content from the
*Backtrace* buffer and either faking non-printable or substituting it
an ellipsis or such.
--
Greetings
Pete
Work is the curse of the drinking class.
– Oscar Wilde
Eli Zaretskii
>
> > What if you only mark strictly printable characters? does it work
> > then?
>
> These can easily be copied. This way I could cite content from the
> *Backtrace* buffer and either faking non-printable or substituting it
> an ellipsis or such.
Someone should implement an encoding that transliterates all
non-printables according to their visual appearance. E.g., the null
character should be encoded as ^@ (2 ASCII characters), etc.
Peter Dyballa
Am 09.03.2008 um 23:41 schrieb Eli Zaretskii:
>>> What if you only mark strictly printable characters? does it work
>>> then?
>>
>> These can easily be copied. This way I could cite content from the
>> *Backtrace* buffer and either faking non-printable or substituting it
>> an ellipsis or such.
>
> Someone should implement an encoding that transliterates all
> non-printables according to their visual appearance. E.g., the null
> character should be encoded as ^@ (2 ASCII characters), etc.
... and \123 as \123 (four characters). This would be a nice service.
Nevertheless, I think the ability to handle decomposed Unicode
characters (the way file names, but not time stamp dates, are
recorded in Mac OS X's HFS+ file system) is more valuable and
important. One could search for such file names and file name
completion would work.