GNU bug report logs - #55767
29.0.50; tramp converts buffer of remote OSX file to utf-8-mac after save

Previous Next

Full log

Message #8 received at 55767 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jake Nelson <jake.nelson <at> gmail.com>
Cc: 55767 <at> debbugs.gnu.org
Subject: Re: bug#55767: 29.0.50; tramp converts buffer of remote OSX file to
 utf-8-mac after save
Date: Wed, 08 Jun 2022 13:09:32 +0200

Jake Nelson <jake.nelson <at> gmail.com> writes:

Hi Jake,

> 1. Visit remote file on an OSX system using
> /scp:hostname:/path/to/file
> 2. Modify buffer
> 3. Save
> 4. Note buffer-file-coding-system has updated to utf-8-mac (and (Mac)
> now listed
> in modeline).
> 5. Modify and Save again and the file line endings will be converted
> to
> carriage returns.

Well, I don't use macOS myself, neither locally nor on a remote
machine. So I hope you can help me to puzzle this out.

> I used git bisect to find commit
> 47fe7a5983a97c3e806e90340f3cd6ab3f0c49b2 introduced this behavior.
> Prior
> to 47fe7a59 emacs would not modify the line endings of the file.   I
> believe utf-8-mac is only for Mac Classic files.

Well, IIRC, 47fe7a59 was just a refactoring of code. It introduced the
new macro tramp-skeleton-write-region in order to simplify Tramp's
different write-region implementations.

Hmm, you are speaking about "Mac Classic files". How could Tramp
determine, whether a remote machine uses this? These days, Tramp calls
"uname -sr". If the result string contains "Darwin", Tramp assumes macOS
on the remote side. Is there something else Tramp shall distinguish for
remote macOS'es?

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.