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

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

[Michael Albinus]

Sebastien Kirche <sebastien.kirche@free.fr> 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 ...).

In general it means that `emerge-file' is not Tramp-ready, because it
will always call diff via `shell-command', independant whether
default-directory of the buffer related to is located on a locale host
or on a remote one.

I fear there's nothing Tramp can do fixing it. It must be done in
`emerge-make-diff-list' or somewhere around.

> 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.

> Regards,
> Sébastien Kirche

Best regards, Michael.

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 <sebastien.kirche@free.fr> 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