GNU bug report logs -
#66255
29.1; package-generate-autoloads utf-8-emacs-unix coding and git on windows breaks
Previous Next
Reported by: Robert <robewald <at> gmx.net>
Date: Thu, 28 Sep 2023 11:16:02 UTC
Severity: wishlist
Tags: notabug, wontfix
Found in version 29.1
Done: Stefan Kangas <stefankangas <at> gmail.com>
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 66255 in the body.
You can then email your comments to 66255 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#66255
; Package
emacs
.
(Thu, 28 Sep 2023 11:16:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Robert <robewald <at> gmx.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 28 Sep 2023 11:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When installing packages on emacs 29.1 the interaction with git on
windows can lead to breakage.
The behaviour can be reproduced on windows with the following steps.
- With an empty .emacs.d:
(install-package 'seq)
observe that .emacs.d/elpa/seq-2.24/seq-autoloads.el is created and
coding at the very bottom is set to utf-8-emacs-unix
- On the command line inside the directory .emacs.d:
git init
git add -A elpa
git commit -m "testing encodings"
rm -rf elpa
git checkout -f master
- now emacs doesn't properly load seq-autoloads.el. Since git converts
the line endings when writing the file, it now has crlf line endings.
This conflicts with the coding set to utf-8-emacs-unix on the
bottom of the file. As a result the error message is shown: "File mode
specification error: (user-error Local variables entry is missing
the suffix)". It is very hard to figure out why this happens.
This used to work in emacs 28.2. There, the coding system of the autoload
files was set to utf-8.
A workaround is to set git config core.autocrlf false in the .emacs.d
repository on windows. This however is hard to discover.
If feasible, I suggest to make the default coding system in the autoloads utf-8 as it
used to be.
In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-07-31 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.3324)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: NOR
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
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 vc-git diff-mode easy-mmode vc-dispatcher
org-element org-persist org-id org-refile avl-tree generator oc-basic
cl-extra help-mode ol-eww eww xdg url-queue thingatpt mm-url ol-rmail
ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view
mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg
dom browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs json map byte-opt gv
bytecomp byte-compile url-vars gnus-group gnus-undo gnus-start gnus-dbus
dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range wid-edit
ol-docview doc-view filenotify jka-compr image-mode exif ol-bibtex
bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete
pcomplete comint ansi-osc ansi-color ring org-list org-footnote
org-faces org-entities noutline outline icons ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol rx org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec emacsbug message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
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
w32notify w32 lcms2 multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 238895 17293)
(symbols 48 20059 2)
(strings 32 71381 2647)
(string-bytes 1 2174421)
(vectors 16 36685)
(vector-slots 8 685024 27084)
(floats 8 336 161)
(intervals 56 362 0)
(buffers 984 12))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#66255
; Package
emacs
.
(Thu, 28 Sep 2023 19:16:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Robert <robewald <at> gmx.net> writes:
> This used to work in emacs 28.2. There, the coding system of the autoload
> files was set to utf-8.
>
> A workaround is to set git config core.autocrlf false in the .emacs.d
> repository on windows. This however is hard to discover.
>
> If feasible, I suggest to make the default coding system in the
> autoloads utf-8 as it used to be.
IIRC, this change was introduced to fix bug#53529[1]. I'm not sure if
reverting this change is a good idea, but I'm not an expert on this.
Best, Arash
Footnotes:
[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-01/msg01721.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#66255
; Package
emacs
.
(Fri, 29 Sep 2023 14:52:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 66255 <at> debbugs.gnu.org (full text, mbox):
tags 66255 notabug wontfix
thanks
> From: Robert <robewald <at> gmx.net>
> Date: Thu, 28 Sep 2023 12:21:54 +0200
>
> When installing packages on emacs 29.1 the interaction with git on
> windows can lead to breakage.
>
> The behaviour can be reproduced on windows with the following steps.
>
> - With an empty .emacs.d:
> (install-package 'seq)
> observe that .emacs.d/elpa/seq-2.24/seq-autoloads.el is created and
> coding at the very bottom is set to utf-8-emacs-unix
>
> - On the command line inside the directory .emacs.d:
> git init
> git add -A elpa
> git commit -m "testing encodings"
> rm -rf elpa
> git checkout -f master
>
> - now emacs doesn't properly load seq-autoloads.el. Since git converts
> the line endings when writing the file, it now has crlf line endings.
> This conflicts with the coding set to utf-8-emacs-unix on the
> bottom of the file. As a result the error message is shown: "File mode
> specification error: (user-error Local variables entry is missing
> the suffix)". It is very hard to figure out why this happens.
You must configure Git on Windows not to convert the line endings.
Nothing else will work reliably on Windows, especially since the Emacs
Git repository has both files with Unix LF-only EOL format and files
with DOS/Windows CR-LF EOL format.
Emacs now assumes that Git on Windows was configured not to convert
EOL format of files when committing or when checking out.
> A workaround is to set git config core.autocrlf false in the .emacs.d
> repository on windows. This however is hard to discover.
This is what everyone should do. (Actually, you should have selected
that option when you installed Git for Windows.) I have this set
globally in my ~/.gitconfig, so it is in effect for all the Git
repositories on my system.
> If feasible, I suggest to make the default coding system in the autoloads utf-8 as it
> used to be.
No, we cannot go back to that, since it produces problems that are
impossible to solve, see the discussion to which Arash pointed. Those
problems are now solved, but te solution assumes that EOL format is
not changed by Git.
Added tag(s) notabug and wontfix.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 29 Sep 2023 14:52:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sat, 30 Sep 2023 23:06:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Fri, 22 Dec 2023 14:53:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Robert <robewald <at> gmx.net>
:
bug acknowledged by developer.
(Fri, 22 Dec 2023 14:53:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 66255-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> tags 66255 notabug wontfix
> thanks
>
>> From: Robert <robewald <at> gmx.net>
>> Date: Thu, 28 Sep 2023 12:21:54 +0200
>>
>> When installing packages on emacs 29.1 the interaction with git on
>> windows can lead to breakage.
>>
>> The behaviour can be reproduced on windows with the following steps.
>>
>> - With an empty .emacs.d:
>> (install-package 'seq)
>> observe that .emacs.d/elpa/seq-2.24/seq-autoloads.el is created and
>> coding at the very bottom is set to utf-8-emacs-unix
>>
>> - On the command line inside the directory .emacs.d:
>> git init
>> git add -A elpa
>> git commit -m "testing encodings"
>> rm -rf elpa
>> git checkout -f master
>>
>> - now emacs doesn't properly load seq-autoloads.el. Since git converts
>> the line endings when writing the file, it now has crlf line endings.
>> This conflicts with the coding set to utf-8-emacs-unix on the
>> bottom of the file. As a result the error message is shown: "File mode
>> specification error: (user-error Local variables entry is missing
>> the suffix)". It is very hard to figure out why this happens.
>
> You must configure Git on Windows not to convert the line endings.
> Nothing else will work reliably on Windows, especially since the Emacs
> Git repository has both files with Unix LF-only EOL format and files
> with DOS/Windows CR-LF EOL format.
>
> Emacs now assumes that Git on Windows was configured not to convert
> EOL format of files when committing or when checking out.
>
>> A workaround is to set git config core.autocrlf false in the .emacs.d
>> repository on windows. This however is hard to discover.
>
> This is what everyone should do. (Actually, you should have selected
> that option when you installed Git for Windows.) I have this set
> globally in my ~/.gitconfig, so it is in effect for all the Git
> repositories on my system.
>
>> If feasible, I suggest to make the default coding system in the autoloads utf-8 as it
>> used to be.
>
> No, we cannot go back to that, since it produces problems that are
> impossible to solve, see the discussion to which Arash pointed. Those
> problems are now solved, but te solution assumes that EOL format is
> not changed by Git.
I'm therefore closing this bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 20 Jan 2024 12:24:15 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 111 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.