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

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

Vincent Belaïche <vincent.belaiche@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.

[-- Attachment #2: Type: text/html, Size: 2809 bytes --]