> > On 19 Jun 2023, at 19.55, Eli Zaretskii wrote: > >> Date: Mon, 19 Jun 2023 12:57:39 +0300 >> From: miranda@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 > > 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 , 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