GNU bug report logs - #66748
29.1; Remote files lose their coding system & line ending style

Previous Next

Package: emacs;

Reported by: Dan McCarthy <daniel.c.mccarthy <at> gmail.com>

Date: Wed, 25 Oct 2023 15:54:02 UTC

Severity: normal

Found in version 29.1

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66748 in the body.
You can then email your comments to 66748 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#66748; Package emacs. (Wed, 25 Oct 2023 15:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan McCarthy <daniel.c.mccarthy <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 25 Oct 2023 15:54:02 GMT) Full text and rfc822 format available.

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

From: Dan McCarthy <daniel.c.mccarthy <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Remote files lose their coding system & line ending style
Date: Wed, 25 Oct 2023 11:52:34 -0400
[Message part 1 (text/plain, inline)]
I visited a remote file with DOS line endings over SSH, added a line and
saved. The file still has \r\n at every line, but now Emacs reports
"Unix-style LF" as the line-ending style; if I add more text and save
again, the line endings are converted to \n.

Something similar happens with remote files in iso-latin-1. After
saving, they're converted to utf-8-unix. I noticed this in `git diff`: it
reported changes in some non-ASCII text that I hadn't touched, which was
surprising.

Neither problem occurs with local files.

In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
 cairo version 1.16.0) of 2023-07-31 built on october.example.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Slackware 15.0 x86_64

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils mule-diag help-mode vc-hg
vc-git diff-mode easy-mmode vc-bzr vc-dispatcher tramp-cache time-stamp
tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat rx shell pcomplete comint ansi-osc ansi-color ring
parse-time iso8601 format-spec auth-source cl-seq eieio eieio-core
cl-macs password-cache json map byte-opt gv bytecomp byte-compile
time-date subr-x cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 79231 16886)
 (symbols 48 9277 0)
 (strings 32 29361 2228)
 (string-bytes 1 924723)
 (vectors 16 23951)
 (vector-slots 8 1006726 172152)
 (floats 8 46 49)
 (intervals 56 356 0)
 (buffers 976 14))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#66748; Package emacs. (Wed, 25 Oct 2023 18:00:02 GMT) Full text and rfc822 format available.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dan McCarthy <daniel.c.mccarthy <at> gmail.com>
Cc: 66748 <at> debbugs.gnu.org
Subject: Re: bug#66748: 29.1; Remote files lose their coding system & line
 ending style
Date: Wed, 25 Oct 2023 19:58:25 +0200
Dan McCarthy <daniel.c.mccarthy <at> gmail.com> writes:

Hi Dan,

> I visited a remote file with DOS line endings over SSH, added a line
> and
> saved. The file still has \r\n at every line, but now Emacs reports
> "Unix-style LF" as the line-ending style; if I add more text and save
> again, the line endings are converted to \n.
>
> Something similar happens with remote files in iso-latin-1. After
> saving, they're converted to utf-8-unix. I noticed this in `git diff`:
> it reported changes in some non-ASCII text that I hadn't touched,
> which was surprising.
>
> Neither problem occurs with local files.

This sounds like bug#65022. Please read the discussion at
https://debbugs.gnu.org/65022, which contains also a patch which you
might try. It will be fixed in the upcoming Emacs 29.2.

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#66748; Package emacs. (Thu, 26 Oct 2023 12:10:02 GMT) Full text and rfc822 format available.

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

From: Dan McCarthy <daniel.c.mccarthy <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 66748 <at> debbugs.gnu.org
Subject: Re: bug#66748: 29.1; Remote files lose their coding system & line
 ending style
Date: Thu, 26 Oct 2023 08:08:36 -0400
[Message part 1 (text/plain, inline)]
Yes, that appears to be the same thing. Thanks for the pointer and sorry
for the duplicate.

Dan

On Wed, Oct 25, 2023 at 1:58 PM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Dan McCarthy <daniel.c.mccarthy <at> gmail.com> writes:
>
> Hi Dan,
>
> > I visited a remote file with DOS line endings over SSH, added a line
> > and
> > saved. The file still has \r\n at every line, but now Emacs reports
> > "Unix-style LF" as the line-ending style; if I add more text and save
> > again, the line endings are converted to \n.
> >
> > Something similar happens with remote files in iso-latin-1. After
> > saving, they're converted to utf-8-unix. I noticed this in `git diff`:
> > it reported changes in some non-ASCII text that I hadn't touched,
> > which was surprising.
> >
> > Neither problem occurs with local files.
>
> This sounds like bug#65022. Please read the discussion at
> https://debbugs.gnu.org/65022, which contains also a patch which you
> might try. It will be fixed in the upcoming Emacs 29.2.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]

Reply sent to Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility. (Thu, 26 Oct 2023 13:21:02 GMT) Full text and rfc822 format available.

Notification sent to Dan McCarthy <daniel.c.mccarthy <at> gmail.com>:
bug acknowledged by developer. (Thu, 26 Oct 2023 13:21:02 GMT) Full text and rfc822 format available.

Message #16 received at 66748-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dan McCarthy <daniel.c.mccarthy <at> gmail.com>
Cc: 66748-done <at> debbugs.gnu.org
Subject: Re: bug#66748: 29.1; Remote files lose their coding system & line
 ending style
Date: Thu, 26 Oct 2023 15:19:34 +0200
Dan McCarthy <daniel.c.mccarthy <at> gmail.com> writes:

Hi Dan,

> Yes, that appears to be the same thing. Thanks for the pointer and
> sorry for the duplicate.

No problem, and thanks for the feedback. I'm closing the bug.

> Dan

Best regards, Michael.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 24 Nov 2023 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 266 days ago.

Previous Next


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