GNU bug report logs - #27391
25.2.50; utf-8 coding cookie is not applied on some specific markdown file

Previous Next

Full log

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Vincent Belaïche <vincent.belaiche <at> gmail.com>, 
 Eli Zaretskii <eliz <at> gnu.org>, 27391-done <at> debbugs.gnu.org
Subject: Re: 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 part 1 (text/plain, inline)]

Vincent Belaïche <vincent.belaiche <at> gmail.com> schrieb am Sa., 17. Juni 2017
um 00:23 Uhr:

>
>
> Le 17/06/2017 à 00:09, Vincent Belaïche a écrit :
> >
> > Le 16/06/2017 à 21:37, Vincent Belaïche a écrit :
> >>
> >> Le 16/06/2017 à 21:15, Vincent Belaïche a écrit :
> > [...]
> >
> >>>
> >> 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:
> >
> >   (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.

[Message part 2 (text/html, inline)]

Previous Next

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