GNU bug report logs - #64164
29.0.92; buffer-file-coding-system changes unexpectedly after saving

Previous Next

Full log

View this message in rfc822 format

From: miranda kastemaa <miranda <at> pulusound.fi>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64164 <at> debbugs.gnu.org
Subject: bug#64164: 29.0.92; buffer-file-coding-system changes unexpectedly after saving
Date: Mon, 19 Jun 2023 23:46:37 +0300

[Message part 1 (text/plain, inline)]

> 
> On 19 Jun 2023, at 19.55, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Date: Mon, 19 Jun 2023 12:57:39 +0300
>> From: miranda <at> pulusound.fi
>> 
>> i am trying to edit remote files on another macOS system, using Tramp's 
>> ssh: method. i am running `emacs -Q`.
>> 
>> when i open any file on this remote system, the initial value of 
>> `buffer-file-coding-system` is what i would expect, i.e. undecided-unix 
>> or utf-8-unix, depending on whether the file contains non-ASCII 
>> characters.
>> 
>> however, after saving the file, `buffer-file-coding-system` suddenly 
>> changes to utf-8-hfs-mac. any subsequent save then changes all the line 
>> endings to CR, which i have not actively used since 2001 or so... :-)
>> 
>> i can use `set-buffer-file-coding-system` to set utf-8-unix, but the 
>> problem then occurs again after the next save. other remotes (Linux 
>> systems) do not exhibit the issue.
>> 
>> Emacs 28.2 works as expected.
> 
> Does this happen only with editing remote files via Tramp, or does it
> also happen when you edit local files on macOS?

only via Tramp.

> If it only happens with Tramp, is it possible for you to login to that
> other system and edit files there locally, in case this is triggered
> by something specific to that system?

yes, i have just now tested the same build on the system in question. with local files, the issue does not occur. but if i use Tramp/ssh: to localhost, or to a third mac, i once again get the unexpected line ending change after saving.

on this system too, 28.2 works as expected.

>> i am using the build from https://emacsformacosx.com/builds <https://emacsformacosx.com/builds>
> 
> I don't know what that is.  Are you sure this uses the official
> sources from the emacs-29.0.92 tarball?

i have not inspected the build process myself, but at https://emacsformacosx.com/about <https://emacsformacosx.com/about>, the author writes:

> The scripts I run basically just configure and build right from the GNU source—I don't add any patches or any extraneous lisp packages. I do include the old Carbon icon on the disk image because I like it better than the new Cocoa icon but it is not enabled by default.
> 
> Emacs is built on various versions of Mac OS X: 10.10 and 10.14 as of 2020-05-12 (64 bit only). All the binaries are combined into a single executable and a small Rust launcher chooses which binary to run based on the machine's OS and architecture.
> 
> Why not just use a fat binary? Because fat binaries can only hold 1 of each architecture and Emacs has multiple x86_64 architectures binaries.
> 
> Why are there multiple x86_64 binaries? Even though recent versions of Emacs contain runtime feature detection, there is an issue with some library dependencies.

best,
miranda

[Message part 2 (text/html, inline)]

Previous Next

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