From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Sat, 17 Jun 2017 14:15:27 +0000 Message-ID: References: <84y3sry47f.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113cffd240ebc805522889f8" X-Trace: blaine.gmane.org 1497708974 11074 195.159.176.226 (17 Jun 2017 14:16:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Jun 2017 14:16:14 +0000 (UTC) To: Vincent =?UTF-8?Q?Bela=C3=AFche?= , Eli Zaretskii , 27391-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 17 16:16:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEWH-0002SK-I5 for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Jun 2017 16:16:09 +0200 Original-Received: from localhost ([::1]:34922 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMEWJ-00060d-Gx for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Jun 2017 10:16:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMEWD-00060S-OI for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:16:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMEWA-00029L-Km for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:16:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50809) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dMEWA-000294-HU for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dMEW9-0003yr-V5 for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:16:01 -0400 Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2017 14:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 27391 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 27391@debbugs.gnu.org, p.stephani2@gmail.com, vincent.belaiche@gmail.com Original-Received: via spool by 27391-done@debbugs.gnu.org id=D27391.149770894615276 (code D ref 27391); Sat, 17 Jun 2017 14:16:01 +0000 Original-Received: (at 27391-done) by debbugs.gnu.org; 17 Jun 2017 14:15:46 +0000 Original-Received: from localhost ([127.0.0.1]:53486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEVu-0003yJ-GB for submit@debbugs.gnu.org; Sat, 17 Jun 2017 10:15:46 -0400 Original-Received: from mail-ot0-f171.google.com ([74.125.82.171]:33246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEVs-0003y4-4E for 27391-done@debbugs.gnu.org; Sat, 17 Jun 2017 10:15:44 -0400 Original-Received: by mail-ot0-f171.google.com with SMTP id y47so23556366oty.0 for <27391-done@debbugs.gnu.org>; Sat, 17 Jun 2017 07:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Wu5JaC9yh9NPV0OQOD/lqNi0Rxagrc34/LPkUhqxSi4=; b=dEyHf8w20B17ATurZ4VrhMcXoLPHBcwLqcOeHtFRO2ZoEiT6blSKUpg+5Rur/Hfp33 QFqUkvDiB3pvEAOYn3H7jBsU5fGPTiA4xUVnTu4EzT+fU8ryjPiTSu5Z8WKycsBSwaTS QXv5+gZKK6BLbAUYP6vI5oAL91TgFJi9LN5iJX9MkLq93NZXisPT1Hj6nhqGn4tlW+T2 r7GX+tm+n3VtQ1YYpNGTi7MCTcVmkicxJ5jy4DcAV/+MX5vQbVeRY4z00xkBWewG/IfI XP5vtw4+ATB9mXkOXuxZi3uPRnT2kVbBi/U6nHpLYSyaWnqUjfw6jwEcpPIc0IOELgvM 7mxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Wu5JaC9yh9NPV0OQOD/lqNi0Rxagrc34/LPkUhqxSi4=; b=LDp8pBd/jL9l02+2R159u3DrYYLf0L0M6JvXj3I2cUjPkmAWG6HeCsjzl+2X5Ky3OW hWU6RMEy7thpFFKaaHTY2pklX8yhuf0Q8jyCc32D8vCpgs/VLhz6eH59eK5xdIQrcA0f ngxb1ZBAFRteNUDAKHX7RnvZAh4Twlw24OQV7S4mhYSCN8uWnHkLW56JWETNdNM3YlPK zEuFlzUC6r3v5wWgr7wo+YdCYMs4xjTqrYCPIgS2LIYpGGqUq6DFSGqg0CznxNXtm/jC 4mxqo69WZ6no5AOguvJIVAW0ud9AuCyszoCfX3Pi2kPWhtm719q5kPk1Jz+/z9wHmxcF mHLQ== X-Gm-Message-State: AKS2vOzuML2Xx0k+AoN8u1QsgG/1YnixiQvqfQBVRhxoiPqXKvQy6cmA Lt3h9L6MeVZ0YfC4ML5JKK1EoB9Obg== X-Received: by 10.157.43.199 with SMTP id u65mr9511357ota.182.1497708938454; Sat, 17 Jun 2017 07:15:38 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133701 Archived-At: --001a113cffd240ebc805522889f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Bela=C3=AFche schrieb am Sa., 17. Juni= 2017 um 00:23 Uhr: > > > Le 17/06/2017 =C3=A0 00:09, Vincent Bela=C3=AFche a =C3=A9crit : > > > > Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : > >> > >> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : > > [...] > > > >>> > >> After some more investigation, I think that the bug is in function > >> insert-file-contents of fileio.c which is the one that decide and sets > >> the coding system well before the other local variables are looked int= o. > > I have located the bug. > > > > After some more investigation, in the end the find-auto-coding of > > mule.el is what is called to detect the coding. > > > > This function evaluates this expression to find the local variables: > > > > (re-search-forward > > "[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ > \t]*\\([^\r\n]*\\)[\r\n]" > > tail-end t) > > > > This expression evaluates to nil over file CONTRIBUTING.md > > > > I can make a simple fix if you tell me on which branch to do it. > > > > However I think that the root of the problem is poor code factorization > > of local variable parsing between mule.el and file.el. A better, more > > futureproof fix would be some unique local variable parser with some > > input constrain telling what sort of setting are sought. The output of > > the parse could be used in file.el and mule.el. > > > > Vincent. > > > > > Ooops... my lengthy email of T23:34 was unwantedly sent. A shorter > version with only the conclusion and w/o all the details of my > investigation is above. > > Anyway, Philipp's patch is what I had in mind as a quick fix. OK, I've pushed this commit as c3813b2aa8d2f5a625195fdbbfe6a01a602d7735. > Although I > don't think that this is a good solution not to factorize code when > possible. Factorizing makes it more maintainable. > Agreed. Note that there's a third place in Emacs that parses a subset of file-local variables: lread.c, to detect the lexical-binding variable when loading ELisp files. Ideally that would be merged as well. --001a113cffd240ebc805522889f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Vincen= t Bela=C3=AFche <vincent.b= elaiche@gmail.com> schrieb am Sa., 17. Juni 2017 um 00:23=C2=A0Uhr:<= br>


Le 17/06/2017 =C3=A0 00:09, Vincent Bela=C3=AFche a =C3=A9crit :
>
> Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>>
>> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : > [...]
>
>>>
>> After some more investigation, I think that the bug is in function=
>> insert-file-contents of fileio.c which is the one that decide and = sets
>> the coding system well before the other local variables are looked= into.
> I have located the bug.
>
> After some more investigation, in the end the find-auto-coding of
> mule.el is what is called to detect the coding.
>
> This function evaluates this expression to find the local variables: >
>=C2=A0 =C2=A0(re-search-forward
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "[\r\n]\\([^[\r\n= ]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tail-end t)
>
> This expression evaluates to nil over file CONTRIBUTING.md
>
> I can make a simple fix if you tell me on which branch to do it.
>
> However I think that the root of the problem is poor code factorizatio= n
> of local variable parsing between mule.el and file.el. A better, more<= br> > futureproof fix would be some unique local variable parser with some > input constrain telling what sort of setting are sought. The output of=
> the parse could be used in file.el and mule.el.
>
>=C2=A0 =C2=A0 Vincent.
>
>
Ooops... my lengthy email of T23:34 was unwantedly sent. A shorter
version with only the conclusion and w/o all the details of my
investigation is above.

Anyway, Philipp's patch is what I had in mind as a quick fix.

OK, I've pushed this commit as c3813b2aa8d2f5a6= 25195fdbbfe6a01a602d7735.
=C2=A0
Although I
don't think that this is a good solution not to factorize code when
possible. Factorizing makes it more maintainable.

Agreed. Note that there's a third plac= e in Emacs that parses a subset of file-local variables: lread.c, to detect= the lexical-binding variable when loading ELisp files. Ideally that would = be merged as well.=C2=A0
--001a113cffd240ebc805522889f8--