> In <[EMAIL PROTECTED]> Kenichi Handa wrote:
> In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes:
>> uudecode.el bundled with Gnus now doesn't work with Emacs 21 and
>> XEmacs because of `string-to-multibyte'.
[...]
>> + (defalias 'uudecode-string-to-multibyte
[..
In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes:
>> In <[EMAIL PROTECTED]> Kenichi Handa wrote:
> > In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
>>> Stefan Monnier <[EMAIL PROTECTED]> writes:
> Which function is it?
I believ
> In <[EMAIL PROTECTED]> Kenichi Handa wrote:
> In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
Which function is it?
>>>
>>> I believe the function "at fault" is uudecode-decode-region
>> Yes, it's uudecode-decode-re
However, the underlying bug in `insert' remains I think.
Stefan Monnier said the problem is that:
| Basically, `insert' uses implicitly string-make-multibyte instead of
| string-to-multibyte.
I am not convinced this is a bug.
___
emac
> So if the root cause of this is in `insert', isn't that where it
> should be fixed? Otherwise there's a risk that there's other code
> which is broken in the same way that uudecode-decode-region was before
> your patch.
Yes, but there's also code that relies on the current behavior.
Now's not t
>> > I've committed a patch based on Chris' proposal.
>> The has fixed the problem with copying the image file using TRAMP's
>> ssh method, thanks.
>> However, the underlying bug in `insert' remains I think.
>> Stefan Monnier said the problem is that:
>> | Basically, `insert' uses implicitly string
In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
> Michael Albinus <[EMAIL PROTECTED]> writes:
> > I've committed a patch based on Chris' proposal.
> The has fixed the problem with copying the image file using TRAMP's
> ssh method, thanks.
> However, the underlying bug in
Kenichi Handa <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
>
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
Which function is it?
>> >
>> > I believe the function "at fault" is uudecode-decode-region
>
>> Yes, it's uudecode-decode-region
In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> Which function is it?
> >
> > I believe the function "at fault" is uudecode-decode-region
> Yes, it's uudecode-decode-region.
Ok, I've just installed a fix to make it work on
Michael Albinus <[EMAIL PROTECTED]> writes:
> I've committed a patch based on Chris' proposal.
The has fixed the problem with copying the image file using TRAMP's
ssh method, thanks.
However, the underlying bug in `insert' remains I think.
Stefan Monnier said the problem is that:
| Basically,
Stefan Monnier <[EMAIL PROTECTED]> writes:
> But independently from whether we fix it or not, I believe that making the
> buffer unibyte is the right thing to do since it will only ever contain
> bytes, and never chars: using a multibyte buffer here is inefficient and is
> asking for trouble.
I'v
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Which function is it?
>
> I believe the function "at fault" is uudecode-decode-region
Yes, it's uudecode-decode-region.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mai
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
> > But, as Stefan wrote, it is better to call
> > (set-buffer-multibyte nil) much earlier.
> > Anyway, it is better to fix the function bound to loc-dec to
> > work in a multibyte buffer too. Which function is it?
> I b
> But, as Stefan wrote, it is better to call
> (set-buffer-multibyte nil) much earlier.
> Anyway, it is better to fix the function bound to loc-dec to
> work in a multibyte buffer too. Which function is it?
I believe the function "at fault" is uudecode-decode-region, although
personally I think
In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes:
> I didn't have uudecode installed on the local machine, so TRAMP was
> using Emacs' Lisp version of uudecode, and using Emacs' write-region
> to save the results to a file.
> tramp.el is careful to bind coding-system-for-wri
> tramp.el is careful to bind coding-system-for-write to 'binary when
> writing the region:
>(let ((coding-system-for-write 'binary))
> (funcall loc-dec (point-min) (point-max))
> (write-region (point-min) (point-max) tmpfil))
> but unf
In article <[EMAIL PROTECTED]>, Chris <[EMAIL PROTECTED]> writes:
> I have a 1 byte file on a remote server. If I use 'scp' to copy the
> file to my local machine, it copies correctly, but if I use:
> $ emacs -Q
> (copy-file "/ssh:[EMAIL PROTECTED]:~/file" "/tmp/file") C-j
> to copy it, then
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> I just tried this, and I cannot reproduce the problem with the
> current CVS: I get an exact replica of the original file on my local
> machine.
I found what was causing the problem:
I didn't have uudecode installed on the local machine, so TRAMP was
u
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> Do _all_ files from that machine copy incorrectly? Or just some?
No. Plain text files copy correctly for example. And I just noticed
that using /scp:... instead of /ssh:... works fine, too. I only used
ssh in the first place because I didn't have ss
> Date: Wed, 10 Jan 2007 21:04:19 +0100
> From: Chris <[EMAIL PROTECTED]>
>
> I have a 1 byte file on a remote server. If I use 'scp' to copy the
> file to my local machine, it copies correctly, but if I use:
> $ emacs -Q
> (copy-file "/ssh:[EMAIL PROTECTED]:~/file" "/tmp/file") C-j
> to copy
I have a 1 byte file on a remote server. If I use 'scp' to copy the
file to my local machine, it copies correctly, but if I use:
$ emacs -Q
(copy-file "/ssh:[EMAIL PROTECTED]:~/file" "/tmp/file") C-j
to copy it, then the resulting local file is 2 bytes long.
I used hexl-mode to compare the tw
21 matches
Mail list logo
