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]"))