Re: New Tramp with uuencode on Windows

[Douglas Gray Stephens]

Kai,

At 23:31 (GMT+0200) on 13-September-2002, Kai Großjohann wrote:
 > I have just uploaded 2.0.19 which has a uuencode implementation in
 > Lisp, so this should also work on Windows, and for Rainer.
 > 
 > It would be really great if you all could test this, pretty please?
 > 
 > Testing is fairly easy: momentarily change tramp-coding-commands such
 > that the uuencode/uudecode entries precede the base64/mimencode
 > entries.  Then use an inline method to open a file on a host which
 > has uuencode/uudecode.
 > 
 > Here's some code you can eval to change tramp-coding-commands (sorry
 > for the long lines):
 > 
 > (setq tramp-coding-commands
 >       '(("uuencode xxx" "uudecode -o -" tramp-uuencode-region 
 > uudecode-decode-region)
 >         ("uuencode xxx" "uudecode -p" tramp-uuencode-region 
 > uudecode-decode-region)
 >         ("uuencode xxx" "tramp_uudecode" tramp-uuencode-region 
 > uudecode-decode-region)
 >         ("mimencode -b" "mimencode -u -b" base64-encode-region 
 > base64-decode-region)
 >         ("mmencode -b" "mmencode -u -b" base64-encode-region 
 > base64-decode-region)
 >         ("recode data..base64" "recode base64..data" base64-encode-region 
 > base64-decode-region)
 >         ("tramp_encode_with_module" "tramp_decode_with_module" 
 > base64-encode-region base64-decode-region)
 >         ("tramp_encode" "tramp_decode" base64-encode-region 
 > base64-decode-region)))

I've grabbed the latest CVS changes, pasted the above into my
 *scratch* buffer, and ended up with the error
 Wrong type argument: stringp, uudecode-decode-region
when trying to do a find-file on
 /plink:address@hidden:work/temp.pl

I've attached debug.txt and tramp.txt.

Your mail to Rainer was based on patching 2.212 of tramp.el, but
CVS version 2.213 appears to have this patch, so I'm not certain why
I'm getting the error.


Consequently I cannot say anything about the 
  At 22:30 (GMT+0200) on 15-September-2002, Rainer Thiel wrote:
 
   <snip>

   > I find disturbing one feature (may I call it a bug?):  When I access 
   > ("find") a file in Emacs, I exspect to see the pertaining buffer in the 
   > current window when the file's been loaded.  This disturbingly is not the 
   > case when accessing a remote file with (tramp and) plink:  I have to dig 
it 
   > from from the buffer list instead.


Cheers,

Douglas.

-- 

================================
Douglas GRAY STEPHENS        
Technical Architect (Directories)
Schlumberger Cambridge Research
High Cross,
Madingley Road,
Cambridge.
CB3 0EL
ENGLAND

Phone  +44 1223 325295
Mobile +44 773 0051628
Fax    +44 1223 311830
Email address@hidden
================================