Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 16. Juni 2017 um
23:39 Uhr:

> Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 16. Juni 2017 um
> 23:34 Uhr:
>
>> Vincent Belaïche <vincent.belaiche@gmail.com> schrieb am Fr., 16. Juni
>> 2017 um 23:28 Uhr:
>>
>>>
>>>
>>> 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.
>>>
>>> After some more investigation, in the end the find-auto-coding of
>>> mule.el is what is called to detect the coding. This function calls some
>>> re-coding regexp.
>>>
>>> Here is a test function defining the same regexp.
>>>
>>>
>>> (defun doit ()
>>>   (interactive)
>>>   (let* ((prefix (regexp-quote "[comment]: # ("))
>>>          (suffix (regexp-quote ")"))
>>>          (re-coding
>>>           (concat
>>>            "[\r\n]" prefix
>>>            ;; N.B. without the \n below, the regexp can
>>>            ;; eat newlines.
>>>            "[ \t]*coding[ \t]*:[ \t]*\\([^ \t\r\n]+\\)[ \t]*"
>>>            suffix "[\r\n]")))
>>>     (message (if (looking-at re-coding) "ok" "nak"))))
>>>
>>> I tried it with point at end of line
>>>
>>> [comment]: # ( Local Variables: )
>>>
>>> and it answered "ok". Now I defined this with re-search-forward instead
>>> of looking-at:
>>>
>>> (defun doit ()
>>>   (interactive)
>>>   (let* ((prefix (regexp-quote "[comment]: # ("))
>>>          (suffix (regexp-quote ")"))
>>>          (re-coding
>>>           (concat
>>>            "[\r\n]" prefix
>>>            ;; N.B. without the \n below, the regexp can
>>>            ;; eat newlines.
>>>            "[ \t]*coding[ \t]*:[ \t]*\\([^ \t\r\n]+\\)[ \t]*"
>>>            suffix "[\r\n]")))
>>>     (message (if (re-search-forward re-coding nil t) "ok" "nak"))))
>>>
>>> I placed the point before the coding: line, and I also got answer "ok"
>>>
>>> So I don't think that the regexp as such is to blame. Something else
>>> seems to happen. It is too late now, I need to go to bed...
>>>
>>>   Vincent.
>>>
>>>
>> I think it's actually the regexp that searches for "Local Variables". The
>> following minimal example fails for me:
>>
>> (with-temp-buffer
>>   (insert "
>>
>> [comment]: # ( Local Variables: )
>> [comment]: # ( coding: utf-8 )
>> [comment]: # ( End: )
>>
>> ")
>> (goto-char (point-min))
>> (re-search-forward
>>  "[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"))
>>
>>
> Does anybody know why the second character range says [^[\r\n] instead of
>  [^\r\n]? This seems to explicitly exclude a leading [.
>

If this is a typo, then here's a patch.