all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Philipp Stephani <p.stephani2@gmail.com>
To: "Vincent Belaïche" <vincent.belaiche@gmail.com>,
	"Eli Zaretskii" <eliz@gnu.org>,
	27391@debbugs.gnu.org
Subject: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file
Date: Fri, 16 Jun 2017 21:52:24 +0000	[thread overview]
Message-ID: <CAArVCkSu-tR-wXS74a2Aqv19P6Ng8Ev7GPYD9ZdQQU2uyuYLZg@mail.gmail.com> (raw)
In-Reply-To: <CAArVCkQmvmwKQMDCqA8-HgJ80Uh=TvJkw=7=3UGmgywf_3O9Ug@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2970 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 4668 bytes --]

[-- Attachment #2: 0001-Allow-local-variables-section-to-begin-with-a-square-b.txt --]
[-- Type: text/plain, Size: 3003 bytes --]

From 2f8bbf7e729ea09addf0d066861a3b38c312141d Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Fri, 16 Jun 2017 23:49:09 +0200
Subject: [PATCH] Allow local variables section to begin with a square bracket

Fixes Bug#27391.

* lisp/international/mule.el (find-auto-coding): Fix regular
expression for "Local Variables" section.

* test/lisp/international/mule-tests.el (find-auto-coding--bug27391):
Add unit test.
---
 lisp/international/mule.el            |  2 +-
 test/lisp/international/mule-tests.el | 39 +++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 test/lisp/international/mule-tests.el

diff --git a/lisp/international/mule.el b/lisp/international/mule.el
index fa3ad80e2f..6cfb7e6d45 100644
--- a/lisp/international/mule.el
+++ b/lisp/international/mule.el
@@ -1970,7 +1970,7 @@ find-auto-coding
 	  (goto-char tail-start)
 	  (re-search-forward "[\r\n]\^L" tail-end t)
 	  (if (re-search-forward
-	       "[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"
+	       "[\r\n]\\([^\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"
 	       tail-end t)
 	      ;; The prefix is what comes before "local variables:" in its
 	      ;; line.  The suffix is what comes after "local variables:"
diff --git a/test/lisp/international/mule-tests.el b/test/lisp/international/mule-tests.el
new file mode 100644
index 0000000000..084f609c45
--- /dev/null
+++ b/test/lisp/international/mule-tests.el
@@ -0,0 +1,39 @@
+;;; mule-tests.el --- unit tests for mule.el         -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2017 Free Software Foundation, Inc.
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Unit tests for lisp/international/mule.el.
+
+;;; Code:
+
+(ert-deftest find-auto-coding--bug27391 ()
+  "Check that Bug#27391 is fixed."
+  (with-temp-buffer
+    (insert "\n[comment]: # ( Local Variables: )\n"
+            "[comment]: # ( coding: utf-8	)\n"
+            "[comment]: # ( End:		)n")
+    (goto-char (point-min))
+    (should (equal (let ((auto-coding-alist ())
+                         (auto-coding-regexp-alist ())
+                         (auto-coding-functions ()))
+                     (find-auto-coding "" (buffer-size)))
+                   '(utf-8 . :coding)))))
+
+;;; mule-tests.el ends here
-- 
2.13.1


  reply	other threads:[~2017-06-16 21:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-16 10:00 bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Vincent Belaïche
2017-06-16 12:59 ` Eli Zaretskii
2017-06-16 14:08 ` Vincent Belaïche
2017-06-16 14:10   ` Vincent Belaïche
2017-06-16 18:38   ` Eli Zaretskii
2017-06-16 19:08     ` Vincent Belaïche
2017-06-16 19:15     ` Vincent Belaïche
2017-06-16 19:31       ` Andreas Schwab
2017-06-16 19:37       ` Vincent Belaïche
2017-06-16 21:27 ` Vincent Belaïche
2017-06-16 21:34   ` Philipp Stephani
2017-06-16 21:39     ` Philipp Stephani
2017-06-16 21:52       ` Philipp Stephani [this message]
2017-06-16 22:09 ` Vincent Belaïche
2017-06-16 22:23   ` Vincent Belaïche
2017-06-17  5:45     ` Vincent Belaïche
2017-06-17 14:30       ` Philipp Stephani
2017-06-19 10:51         ` Vincent Belaïche
2017-06-26 11:39           ` Philipp Stephani
2017-06-27  6:05             ` Vincent Belaïche
2017-06-17 14:15     ` Philipp Stephani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAArVCkSu-tR-wXS74a2Aqv19P6Ng8Ev7GPYD9ZdQQU2uyuYLZg@mail.gmail.com \
    --to=p.stephani2@gmail.com \
    --cc=27391@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=vincent.belaiche@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.