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