Re: tramp (2.0.44); emerge-files fails with remote ssh file

[Seki]

Thanks to your usefull clues, i have managed to emerge-file.
Yeah! \o/

Tramp seems to be out of concern about my problem, however it may
have things to do for emerge-files as described below.

Le 16 sept. 2004, à 0:20, Michael Albinus a écrit :

> Sebastien Kirche <address@hidden> writes:
>
> > emerge-file fails with the following :
> > ,----
> > | diff: /tmp/tramp.3617GRY: Aucun fichier ou répertoire de ce type
> > | diff: /Users/seki/.emacs: Aucun fichier ou répertoire de ce type
> > `----
> > Error is french for 'no such file or directory'
> > Both remote and local files are already loaded in the 2 windows.
>
> Indeed. In the actual debug buffer you've provided, the following
> traces are seen:
>
> $ diff  /tmp/tramp.406Ykj /Users/seki/.emacs; tramp_old_status=$?
> diff: /tmp/tramp.406Ykj: Aucun fichier ou répertoire de ce type
> diff: /Users/seki/.emacs: Aucun fichier ou répertoire de ce type
>
> This means, that Tramp has been instructed by `emerge-files' to
> perform the diff command on the remote host. But both files reside on
> the local host; it MUST fail therefore.
>
> I suspect it depends on the order you take the files: it will work if
> the local file is the first one chosen, and the remote file is the
> second one; and it will fail if you apply them the reverse order. (Or
> vice-versa; don't blame me ...).

That's it, I used for all my attempts to give my remote file at first 
and
local file as second.
Changing the order (that is: local as A and remote as B) fixed the
'No such file' problem, even if i cant figure at all why it makes a 
difference
between these two alternatives ...

> > I had also once another fail with the following
> > ,----
> > | \ No newline at end of file
> > | \ No newline at end of file
> > `----
> > The files used to have a final newline, but i have added one and it 
> > seems to
> > be fixed (?)
>
> In your debug buffer there are several encoded files. Your remote file
> "/home/seki/.emacs" contains "^M" as EOL character. Maybe
> `emerge-files' has a problem with that.

Changing the file order let me fall back to this second problem.
Actually the file i attempted to merge was initially created on OSX 
with mac-roman
encoding and mac EOL's.
I changed that to 8859-1 for GNU/Linux at home, forgot that mac EOL 
remained (as
displayed in the mode bar).
Thus i though that emerge cannot merge inconsistent EOL files and fixed 
the file
with mac EOL to 8859-1-unix encoding. Emerge-files then worked 
perfectly.

But i have also tried to emerge 2 files that were both 8859-1-mac 
encoded and emerge
failed with the same problem 'no newline at end'.
So it seems that emerge can just merge unix encoded files ?

Anyway it works now for me, and i have a recipe for my further merges :)
Thank you very much Michael !

Sébastien Kirche