GNU bug report logs - #46117
12.3.1; windows unfriendly change

Previous Next

Package: auctex;

Reported by: Matt Stinson <mrmatt2532 <at> gmail.com>

Date: Tue, 26 Jan 2021 17:44:02 UTC

Severity: normal

Tags: fixed

Found in version 12.3.1

Done: Ikumi Keita <ikumi <at> ikumi.que.jp>

Bug is archived. No further changes may be made.

Full log


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

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Matt Stinson <mrmatt2532 <at> gmail.com>
Cc: 46117 <at> debbugs.gnu.org
Subject: Re: bug#46117: 12.3.1; windows unfriendly change
Date: Wed, 27 Jan 2021 16:53:46 +0900
Hi Matt,

>>>>> Matt Stinson <mrmatt2532 <at> gmail.com> writes:
> When the auctex builds I receive the following error related to tex-jp.el:
> "local variables

> entry is missing the suffix"

I assume the following two:
(1) You are using git for windows which enables autocrlf feature.
(2) You built AUCTeX on a local copy of git repository.
(Actually I couldn't reproduce the problem by just copying the files to
my windows 10 and running configure and make with msys. It's only after
a web search with the keywords "local variables entry is missing the
suffix" that I realized what's going on by references such as:
https://github.com/hlissner/doom-emacs/issues/2637
https://github.com/raxod502/straight.el/issues/346
https://github.com/tumashu/helm-posframe/pull/9
https://github.com/ikirill/irony-eldoc/pull/13
)
The autocrlf feature silently converts the eol of the files in the
working directory from LF to CRLF, which ends up with contradicting
coding: tag specified in tex-jp.el.

I think that the proper approach for this issue is to turn off the
autocrlf feature for at least the local AUCTeX repository, but at the
same time think that it isn't bad to make AUCTeX more generous to
loosely configured local git repos. I'll remove eol suffix from coding:
tag.

> The recent change to tex-jp.el (commit:
> 384c1d2528eba44cd53d8ea42e151c7b4445bafd) appears to have added a

> windows unfriendly coding.

> I think rather than

> coding: iso-2022-jp-unix

> it should be

> coding: iso-2022-jp

I don't think it's windows unfriendly. As stated above, the current tag
coding: iso-2022-jp-unix
works fine even on windows if the file is copied as-is, without eol
format conversion. In my opinion, it's more of the problem on the side
of git for windows, with respect to the status of autocrlf feature.

Regards,
Ikumi Keita




This bug report was last modified 4 years and 113 days ago.

Previous Next


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