Re: tramp+recentf: persistent errors due to expand-file-name

[David Reitter]

On 11 Aug 2008, at 21:18, Michael Albinus wrote:
> I cannot reproduce it here:

Me neither, not with an Emacs -Q (22 or 23) and such a minimal  
example.  Sorry!

> This leaves `name' in an unexpanded state, which might be not
> desirable.

Better than throwing a signal that is not handled, preventing the user  
from saving a file.

> I would prefer to find the reason, why Tramp returns it the
> way you have shown (and I cannot reproduce).

Me to.
I looked into this some more and I now think that there is something  
more complex going on that leads to the malformed URL ending up in the  
recentf-list.  This could be because I have code that synchronizes  
`file-name-history' and `recentf-list', and in my Emacs 22, `file-name- 
history' contains malformed tramp locations, while this doesn't seem  
to be the case in 23.  Also, it appears that the // is handled  
correctly in 23 (but wasn't in 22).  So, the problem might not occur  
in 23 anyways.  The particular chain of events may not be worth our  
time.

Generally, I do think it is prudent to guard against errors being  
signaled when running code from hooks so that users don't end up in a  
(to them) non-recoverable situation.  You'll know best where the right  
place is...

- D

smime.p7s
Description: S/MIME cryptographic signature