[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Philipp Stephani
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]