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

["Vincent Belaïche" <vincent.belaiche@gmail.com>]

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. Although I
don't think that this is a good solution not to factorize code when
possible. Factorizing makes it more maintainable.

  V.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus