From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 06:00:32 2017 Received: (at submit) by debbugs.gnu.org; 16 Jun 2017 10:00:32 +0000 Received: from localhost ([127.0.0.1]:50254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLo3L-00079c-IG for submit@debbugs.gnu.org; Fri, 16 Jun 2017 06:00:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLo3J-00079O-K3 for submit@debbugs.gnu.org; Fri, 16 Jun 2017 06:00:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLo3C-0007Uv-FU for submit@debbugs.gnu.org; Fri, 16 Jun 2017 06:00:24 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dLo3C-0007Ur-Ch for submit@debbugs.gnu.org; Fri, 16 Jun 2017 06:00:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLo3A-00021Q-Hs for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 06:00:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLo36-0007Rj-EJ for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 06:00:20 -0400 Received: from smtp01.smtpout.orange.fr ([80.12.242.123]:27438 helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dLo35-0007PE-UK for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2017 06:00:16 -0400 Received: from AigleRoyal ([90.32.171.63]) by mwinf5d24 with ME id ZN081v00C1NRGYS03N08xU; Fri, 16 Jun 2017 12:00:12 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Fri, 16 Jun 2017 12:00:12 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: bug-gnu-emacs@gnu.org Subject: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Fri, 16 Jun 2017 12:00:06 +0200 Message-ID: <841sqkdzh5.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170615-0, 15/06/2017), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.4 (--) X-Debbugs-Envelope-To: submit Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I was editing some file written in Markdown. Here is the file : https://framagit.org/latex-pourquoi-comment/lpc-articles/blob/795ecb9d4f7b8= 870486fe6557f01d2fe450c4461/CONTRIBUTING.md My Emacs default configuration was to get files in latin-1. So I had added some `coding: utf-8' cookie in this file. But it did not work, the file was still read in latin-1 instead of utf8. I made a test with one more cookie `eval: (message "Hello")', this one worked, which means that the problem is not that cookies aren't read, the problem is within the application of the coding scheme. The only way for me to get the correct encoding is to place: (modify-coding-system-alist 'file "\\.m\\(d\\|arkdown\\)\\'" 'prefer-utf-8) In my init file. I made the trial with `emacs -q', and the problem is still there, which shows that markdown-mode is not to blame. My first thought was that markdown-mode was the culprit, see discussion here : https://github.com/jrblevin/markdown-mode/issues/198 Jason Blevin is the author of markdown-mode, he noted that the presence of the [ character has some impact. See: https://github.com/jrblevin/markdown-mode/issues/198#issuecomment-308524696= I did not double check his analysis. To me this looks like some race problem where the automatic encoding detection is applied after the cookie and undoes it. Maybe some semaphore is missing, or something like that. Vincent. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D In GNU Emacs 25.2.50.1 (i686-pc-mingw32) of 2017-06-14 built on AIGLEROYAL Repository revision: da62c1532e479bbac4ce242ee1d170df9c435591 Windowing system distributor 'Microsoft Corp.', version 10.0.14393 Configured using: 'configure --prefix=3Dc:/Nos_Programmes/GNU/Emacs --without-jpeg --without-tiff --without-gif --without-png 'CFLAGS=3D -Og -g3 -L C:/Programmes/installation/emacs-install/libXpm-3.5.8/src' 'CPPFLAGS=3D -DFOR_MSW=3D1 -I C:/Programmes/installation/emacs-install/libXpm-3.5.8/include -I C:/Programmes/installation/emacs-install/libXpm-3.5.8/src -L C:/Programmes/installation/emacs-install/libXpm-3.5.8/src'' Configured features: XPM SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS Important settings: value of $LANG: FRA locale-coding-system: cp1252 Major mode: Dired by name Minor modes in effect: diff-auto-refine-mode: t TeX-PDF-mode: t shell-dirtrack-mode: t recentf-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Recent messages: Mark set [2 times] Mark saved where search started Quit scroll-up-command: End of buffer Mark set find-dired *Find* finished. dired-get-file-for-visit: No file on this line [2 times] Mark set Quit Making completion list... Load-path shadows: c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs h= ides c:/Nos_Programmes/GNU/Emacs/share/emacs/25.2.50/lisp/loaddefs c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs h= ides c:/Programmes/installation/cedet-install/cedet-git/lisp/cedet/loaddefs= Features: (shadow emacsbug find-dired calc-yank calc-mode calccomp calc-alg calc-vec calc-aent calc-menu cal-move whitespace perl-mode log-edit pcvs-util eieio-opt speedbar sb-image ezimage dframe vc-bzr vc-src vc-sccs vc-svn vc-rcs vc-dir ewoc add-log org-element org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view subr-x jka-compr image-mode org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs tex-info texinfo vc vc-dispatcher ediff-vers thingatpt rect visual-basic-mode sh-script smie executable make-mode misearch multi-isearch ediff-merg ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff vc-git diff-mode reftex-dcr reftex reftex-vars preview prv-emacs noutline outline pcmpl-unix latexenc tex-bar latex easy-mmode tex-style toolbar-x font-latex plain-tex tex-buf tex advice tex-mode compile shell pcomplete comint ansi-color ring bbdb-print info mailalias smtpmail sort ispell vc-cvs hl-line balance eieio-compat calc-forms dired-aux mail-extr bbdb-message sendmail gnus-async qp gnus-ml cursor-sensor nndraft nnmh nnfolder bbdb-gnus bbdb-mua bbdb-com crm network-stream nsm auth-source eieio eieio-core starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range message dired-x dired format-spec rfc822 mml mml-sec password-cache epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader gnus-util mail-utils mm-util help-fns mail-prsvr edmacro kmacro skeleton calc-misc calc-arith calc-ext calc calc-loaddefs calc-macs tex-mik preview-latex tex-site auto-loads bbdb bbdb-site timezone bbdb-loaddefs template w32utils cl-seq cl-macs cl recentf tree-widget wid-edit load-path-to-cedet-svn finder-inf package epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 multi-tty make-network-process emacs) Memory information: ((conses 8 899957 158092) (symbols 32 53590 0) (miscs 32 2257 2796) (strings 16 133750 20600) (string-bytes 1 5975277) (vectors 8 55330) (vector-slots 4 1716681 54830) (floats 8 651 494) (intervals 28 72632 8079) (buffers 516 78)) --- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 08:59:46 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 12:59:46 +0000 Received: from localhost ([127.0.0.1]:50420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLqqo-0006da-0c for submit@debbugs.gnu.org; Fri, 16 Jun 2017 08:59:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLqqn-0006dO-1P for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 08:59:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLqqd-0000lj-0l for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 08:59:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLqqc-0000lb-TV; Fri, 16 Jun 2017 08:59:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4719 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dLqqc-00021C-2n; Fri, 16 Jun 2017 08:59:34 -0400 Date: Fri, 16 Jun 2017 15:59:23 +0300 Message-Id: <83lgos142c.fsf@gnu.org> From: Eli Zaretskii To: vincent.belaiche@gmail.com (Vincent =?utf-8?Q?Bela=C3=AFche?=) In-reply-to: <841sqkdzh5.fsf@gmail.com> (vincent.belaiche@gmail.com) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file References: <841sqkdzh5.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 27391 Cc: 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) > From: vincent.belaiche@gmail.com (Vincent Belaïche) > Date: Fri, 16 Jun 2017 12:00:06 +0200 > Cc: Vincent Belaïche > > I was editing some file written in Markdown. Here is the file : > > https://framagit.org/latex-pourquoi-comment/lpc-articles/blob/795ecb9d4f7b8870486fe6557f01d2fe450c4461/CONTRIBUTING.md > > My Emacs default configuration was to get files in latin-1. So I had > added some `coding: utf-8' cookie in this file. But it did not work, the > file was still read in latin-1 instead of utf8. I cannot reproduce this, and I don't see any coding cookies in the file I downloaded. Please provide a minimal recipe that's required to reproduce the problem. In particular, since you tried in "emacs -q", I don't understand what does it mean that your default configuration is latin-1: in "emacs -q" your default configuration is determined by your system locale. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 10:08:26 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 14:08:26 +0000 Received: from localhost ([127.0.0.1]:51454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLrvG-00009J-4C for submit@debbugs.gnu.org; Fri, 16 Jun 2017 10:08:26 -0400 Received: from smtp13.smtpout.orange.fr ([80.12.242.135]:17793 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLrvE-00008r-3l for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 10:08:24 -0400 Received: from AigleRoyal ([90.32.171.63]) by mwinf5d75 with ME id ZS8B1v0031NRGYS03S8By7; Fri, 16 Jun 2017 16:08:17 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Fri, 16 Jun 2017 16:08:17 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: 27391@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Fri, 16 Jun 2017 16:08:09 +0200 Message-ID: <84r2ykc9fa.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Antivirus: Avast (VPS 170616-0, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Le 16/06/2017 =E0 14:59, Eli Zaretskii a =E9crit : >> From: vincent.belaiche@gmail.com (Vincent Bela=EFche) >> Date: Fri, 16 Jun 2017 12:00:06 +0200 >> Cc: Vincent Bela=EFche >> >> I was editing some file written in Markdown. Here is the file : >> >> https://framagit.org/latex-pourquoi-comment/lpc-articles/blob/795ecb9d4f= 7b8870486fe6557f01d2fe450c4461/CONTRIBUTING.md >> >> My Emacs default configuration was to get files in latin-1. So I had >> added some `coding: utf-8' cookie in this file. But it did not work, the= >> file was still read in latin-1 instead of utf8. > > I cannot reproduce this, and I don't see any coding cookies in the > file I downloaded. > > Please provide a minimal recipe that's required to reproduce the > problem. In particular, since you tried in "emacs -q", I don't > understand what does it mean that your default configuration is > latin-1: in "emacs -q" your default configuration is determined by > your system locale. > > Thanks. Attached is the file causing the issue. Recipe is just to visit the file with emacs -q, and you see that the encoding is not taken. For instance I get the following doc section : --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- ### doc Placez dans *doc* et ses sous-r=C3=A9pertoires toute la documentation aff= =C3=A9rente au projet, sans oublier les notes et courriers =C3=A9lectroniqu= es importants. Vous pouvez avoir des sous-r=C3=A9pertoires de doc contenant= diff=C3=A9rents types de documents ou pour diff=C3=A9rentes phases du proj= et. --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- Instead of: --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- ### doc Placez dans *doc* et ses sous-r=E9pertoires toute la documentation aff=E9re= nte au projet, sans oublier les notes et courriers =E9lectroniques importan= ts. Vous pouvez avoir des sous-r=E9pertoires de doc contenant diff=E9rents = types de documents ou pour diff=E9rentes phases du projet. --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- Vincent. --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. https://www.avast.com/antivirus --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline; filename=CONTRIBUTING.md Content-Transfer-Encoding: quoted-printable Guide de contribution =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WorkFlow -------- Ce projet utilise Git-flow au pied de la lettre: * http://nvie.com/posts/a-successful-git-branching-model/ L'article de base qui donnera naissance au projet * https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html Aide m=C3=A9moire fran=C3=A7ais (et en d'autre traduction). Contributions ------------- Libre =C3=A0 vous de cloner le d=C3=A9p=C3=B4t... Et de proposer des modifi= cations. Conventions de nomnage =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Arborescence de fichier ----------------------- ### doc Placez dans *doc* et ses sous-r=C3=A9pertoires toute la documentation aff= =C3=A9rente au projet, sans oublier les notes et courriers =C3=A9lectroniqu= es importants. Vous pouvez avoir des sous-r=C3=A9pertoires de doc contenant= diff=C3=A9rents types de documents ou pour diff=C3=A9rentes phases du proj= et. Si vous avez besoin de documentation externe, envisager de la copier ici. C= ela rendra service pour maintenir le projet si l'endroit o=C3=B9 les donn= =C3=A9es en questions =C3=A9taient accessibles dispara=C3=AEt. ### src Ce r=C3=A9pertoire contient le code source du projet. Vous pouvez y faire d= es sous-r=C3=A9pertoires pour diff=C3=A9rents types de code source, par exe= mple: * src/inc * src/img * ... ### util R=C3=A9pertoire contenant les utilitaires, outils et scripts sp=C3=A9cifiqu= es au projet. ### vendor Si le projet utilise des biblioth=C3=A8ques fournies par une partie tierce = ou des fichiers d'en-t=C3=AAtes que vous d=C3=A9sirez archiver avec votre c= ode, faites-le ici. Gestionnaire de version ----------------------- Le workflow git suit scrupuleusement git-flow. ### Branche **master** Elle repr=C3=A9sente le dernier =C3=A9tat installable en production du proj= et. Seul les administrateurs du d=C3=A9p=C3=B4t peuvent travailler dans cet= te branche. ### Branche **devel** La branche o=C3=B9 est r=C3=A9colt=C3=A9 le travail de tout le monde, des b= ranches de d=C3=A9veloppement priv=C3=A9es. Seul la "Team" peut travailler = dans cette branche. ### les branches **feature** Chaque branche doit =C3=AAtre Nomm=C3=A9e de la mani=C3=A8re suivante: * PSEUDO-DESCRIPTION o=C3=B9: * **PSEUDO** est le pseudo de l'administrateur (le cr=C3=A9ateur) de la bra= nche * **DESCRIPTION** Une description en CamelCase (RaisonCreationBranche) de c= ette branche [comment]: # ( Local Variables: ) [comment]: # ( coding: utf-8 ) [comment]: # ( eval: (message "Coucou") ) [comment]: # ( End: ) =09=09=09=09 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 10:11:08 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 14:11:08 +0000 Received: from localhost ([127.0.0.1]:51458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLrxr-0000DO-P6 for submit@debbugs.gnu.org; Fri, 16 Jun 2017 10:11:07 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:37219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLrxp-0000Ct-LZ for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 10:11:06 -0400 Received: by mail-wm0-f54.google.com with SMTP id d73so24965424wma.0 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 07:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0jIFiYxXr9xIKJ3S6TXDmN8d7vLfLVN1nWxcAZdEbf8=; b=QmvMSFDwW82SM5A2AfiKPPv+KaD/a9Y03p8l8YIeeWsoC4L3lppcQ9kF65R9X05yfh kaAamlYBkmVZsRkJDRKcD+jSbfVBPa8FqEo/ReiMXd2PKlT3KGE4QpJF6TBPYHiYBzyp Z2dKbnfL9l5f/Tm+C8h1JwGPuPfwdSMn0s5OeYIAHR4pZlRJkEdu7gANPulcDvAkmKII MPfR3/+J36Lcjc7I8Oau4bQ03YN749u2ksl1KtUN+IgCL7fH3iFCL+YUms6KxmQus54B lArtsTaIerMCtxtotBwlRNrSbH6XjGvPOyslShHxCsVKgFpFffdGMK8Dkx0z4pdBwFQF DNFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0jIFiYxXr9xIKJ3S6TXDmN8d7vLfLVN1nWxcAZdEbf8=; b=tYxD5ApQymjgGs3Q4GcWHKLqc5RgGPJmq6/1gj9K4QSX0XOxXr4zLIfrGYSf5MI6/u hC6vYjI9bAtB/JWOfro5+v0wF2uLClvbJZD5oa7Og2mHqHjsN6j0vtoENK0WuX5tavZJ +oSSYt8gYOVIgPCPVMZa12TFQUjHGd0pJygPkeYhAdqj78ERMKSxtFDXeIZuSYDQ0HzP sX89ierNh+kAqr5HJ1QJD9Mj6B8c6qcw7i63buuOfECS3livs6DFjRYk1sP8WXJc7daZ qdOV9tXL2QDziTik+ggAGsuuLEmTTIjDd6EnC3VaKH7rxPlCZDdRMoEBcmhwBt2MwVEj tnkQ== X-Gm-Message-State: AKS2vOxjjks2lWUg758Y4jLJf5WpRG8UBri/KiJW1TWGDVJW6ct44iip G/fKGnqgE+uRhA== X-Received: by 10.28.59.212 with SMTP id i203mr7195989wma.18.1497622259954; Fri, 16 Jun 2017 07:10:59 -0700 (PDT) Received: from [192.168.1.19] (ARennes-656-1-267-63.w90-32.abo.wanadoo.fr. [90.32.171.63]) by smtp.googlemail.com with ESMTPSA id r142sm2307426wmg.24.2017.06.16.07.10.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 07:10:59 -0700 (PDT) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: 27391@debbugs.gnu.org, Eli Zaretskii References: <84r2ykc9fa.fsf@gmail.com> From: =?UTF-8?Q?Vincent_Bela=c3=afche?= Message-ID: <5bdc93b6-5c77-e220-731f-9569175ff3b7@gmail.com> Date: Fri, 16 Jun 2017 16:10:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <84r2ykc9fa.fsf@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 170616-0, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 à 16:08, Vincent Belaïche a écrit : > Le 16/06/2017 à 14:59, Eli Zaretskii a écrit : >>> From: vincent.belaiche@gmail.com (Vincent Belaïche) >>> Date: Fri, 16 Jun 2017 12:00:06 +0200 >>> Cc: Vincent Belaïche >>> >>> I was editing some file written in Markdown. Here is the file : >>> >>> https://framagit.org/latex-pourquoi-comment/lpc-articles/blob/795ecb9d4f7b8870486fe6557f01d2fe450c4461/CONTRIBUTING.md >>> >>> My Emacs default configuration was to get files in latin-1. So I had >>> added some `coding: utf-8' cookie in this file. But it did not work, the >>> file was still read in latin-1 instead of utf8. >> I cannot reproduce this, and I don't see any coding cookies in the >> file I downloaded. >> >> Please provide a minimal recipe that's required to reproduce the >> problem. In particular, since you tried in "emacs -q", I don't >> understand what does it mean that your default configuration is >> latin-1: in "emacs -q" your default configuration is determined by >> your system locale. >> >> Thanks. > Attached is the file causing the issue. Recipe is just to visit the file > with emacs -q, and you see that the encoding is not taken. > > For instance I get the following doc section : > > --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- > ### doc > Placez dans *doc* et ses sous-répertoires toute la documentation afférente au projet, sans oublier les notes et courriers électroniques importants. Vous pouvez avoir des sous-répertoires de doc contenant différents types de documents ou pour différentes phases du projet. > --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- > > Instead of: > > --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- > ### doc > Placez dans *doc* et ses sous-répertoires toute la documentation afférente au projet, sans oublier les notes et courriers électroniques importants. Vous pouvez avoir des sous-répertoires de doc contenant différents types de documents ou pour différentes phases du projet. > --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- > > Vincent. > > > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. > https://www.avast.com/antivirus Just for the clarification, you needed to click on the open raw button to see the cookie. I should have sent you this link : https://framagit.org/latex-pourquoi-comment/lpc-articles/raw/795ecb9d4f7b8870486fe6557f01d2fe450c4461/CONTRIBUTING.md Instead of the "viewer" equivalent link, where the markdown tags are interpreted into formatting. You cannot see the cookies with the viewer link because they are commented out, so the viewer does not display them. V. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 14:38:55 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 18:38:55 +0000 Received: from localhost ([127.0.0.1]:51679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLw91-0001xr-2v for submit@debbugs.gnu.org; Fri, 16 Jun 2017 14:38:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLw8z-0001xc-Rg for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 14:38:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLw8o-0004b3-5T for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 14:38:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLw8o-0004ay-1o; Fri, 16 Jun 2017 14:38:42 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4978 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dLw8n-0002fq-6t; Fri, 16 Jun 2017 14:38:41 -0400 Date: Fri, 16 Jun 2017 21:38:25 +0300 Message-Id: <83y3srzske.fsf@gnu.org> From: Eli Zaretskii To: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) In-reply-to: <84r2ykc9fa.fsf@gmail.com> (vincent.belaiche@gmail.com) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file References: <84r2ykc9fa.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 27391 Cc: 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) > From: vincent.belaiche@gmail.com (Vincent Belaïche) > Cc: Vincent Belaïche > Date: Fri, 16 Jun 2017 16:08:09 +0200 > > Attached is the file causing the issue. Recipe is just to visit the file > with emacs -q, and you see that the encoding is not taken. Your fancy comment causes this: remove the leading '[' and the problem goes away. Looks like regex-quoting that somehow misfires. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 15:08:29 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 19:08:29 +0000 Received: from localhost ([127.0.0.1]:51688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwbd-0002de-Gr for submit@debbugs.gnu.org; Fri, 16 Jun 2017 15:08:29 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwba-0002dQ-HG for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 15:08:26 -0400 Received: by mail-wm0-f43.google.com with SMTP id x70so33561918wme.0 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 12:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eo5ZtOOlu/fuMKXP0lKmSLaomDy/2655SEmXO1K+7sE=; b=I/TycF7SkML7SZUUYhRWkjbqaMonyW0mU9bwb0hA/zwiYit+Jk0I1zm6ozPdQ/nun0 Fu56054lkDGq0CiSJXfgs4BhgSs8cDE4olH3RAwv4IKQ73HjC6ro1EXu1KwKoE1JpRj4 39twP8IqI0EU8h+dVCpNc/6hgPs4yveWzu/STl4tuulKtzR7Q01+FYGW5ULABIniOmEo imHo9ecwIAdSw2B4OSr9ftHi1OwE2lopqXdfq1McovhqLk8bk4E4fZtH3VpO69tcnbYX duNLPgHjSZJsNlO5qtc9q8OM5/+XQpaeU3Sco4VcMlyMUkZdNEfwJ8HX8c8rb7Led008 fctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eo5ZtOOlu/fuMKXP0lKmSLaomDy/2655SEmXO1K+7sE=; b=gbwBP7SkioJivfJGXf5o5OMIHO1jCXnbLOBl+5vqbJ+DJGQkQLEtmxpVyNvk6sQRbL F8YFzbxiwlhbiVzCh4/oPVMTm9P9a48DQ5Yg67iM+oiGiVO/wFLZ+TppHgSwhWAAvnSb BRBk+SJdwqCEtx6Xu0I4MY7d6eRwaJOmsq9eQ6NsRw/wmmZ2cd7djjn5rdKO5v7bSgAY TTPDnoyNetTWlES30+O+E8YWwHqLzCtDfVG3wfN0yGB7ZR6CvgI7opjYTN3nCDvtuqSq E3DXMVo7YxFGzOhcIsMnKzIW1eOs8PazGQ4GZKkV7y5+5ImHKNUtXTUYK+pS2rVnUePc bgEw== X-Gm-Message-State: AKS2vOxoNcJ0Rw/gbJrq3i9DedmJ6fVN0C2kxXzzVjTa9plYM1CuOeBx c1HrtOS3hLPf6boDa00= X-Received: by 10.28.134.3 with SMTP id i3mr8226751wmd.1.1497640100260; Fri, 16 Jun 2017 12:08:20 -0700 (PDT) Received: from [192.168.1.19] (ARennes-656-1-267-63.w90-32.abo.wanadoo.fr. [90.32.171.63]) by smtp.googlemail.com with ESMTPSA id x8sm1796670wrd.29.2017.06.16.12.08.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 12:08:19 -0700 (PDT) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: Eli Zaretskii References: <84r2ykc9fa.fsf@gmail.com> <83y3srzske.fsf@gnu.org> From: =?UTF-8?Q?Vincent_Bela=c3=afche?= Message-ID: <41e54d35-ee1f-5c32-d6db-dabf03adddfd@gmail.com> Date: Fri, 16 Jun 2017 21:08:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <83y3srzske.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 170616-0, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 à 20:38, Eli Zaretskii a écrit : >> From: vincent.belaiche@gmail.com (Vincent Belaïche) >> Cc: Vincent Belaïche >> Date: Fri, 16 Jun 2017 16:08:09 +0200 >> >> Attached is the file causing the issue. Recipe is just to visit the file >> with emacs -q, and you see that the encoding is not taken. > Your fancy comment causes this: remove the leading '[' and the problem > goes away. Looks like regex-quoting that somehow misfires. I used this type of comment marks after reading this discussion: https://stackoverflow.com/questions/4823468/comments-in-markdown V. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 15:15:48 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 19:15:48 +0000 Received: from localhost ([127.0.0.1]:51694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwii-0002nq-AY for submit@debbugs.gnu.org; Fri, 16 Jun 2017 15:15:48 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:35087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwig-0002nd-KT for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 15:15:46 -0400 Received: by mail-wm0-f53.google.com with SMTP id x70so33684781wme.0 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 12:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rTvIzqpzmsryPZY5eF82cA9z8E5bo7ElOwTN4uBQ2Wg=; b=CA4j5bXyReXw3a7kMZ5bBoZ7Eb+iufYWCWxlVVmiV6FEY2dQpooBmGr5/A9r2e8xfM 9/lWzOxw+QWyuWBxxr0nAhe6ngEIPKsargErMWTJ+fh9vTGw+zqR9JNk/5YI94vEAipd m9FdMKfn4NjToeJlS4THT5Yqdp65IvVGBZqu0htvLzmpmxlFuVuCHgbMlONBe7xhmEds HcsRDbFDSiv09QsITrvXy0rpXCOsvPsOyCIAyhMmd7hXi51Egr7M4ftWP3F4IaHmo2Z4 Jpd1fHghmDeNsw/uAMDJun1eW9HP24N2GlpQUAnyvhVS+lABrUoN88GDO6pRUPeZMdD5 CFXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rTvIzqpzmsryPZY5eF82cA9z8E5bo7ElOwTN4uBQ2Wg=; b=FWWl50QJcaH0wkr6E7DHjL3OaGcb/lNe6DMWgJG88+GgiE8/1K9kLhkVTdh35VPc4x l5YAWvTQMAlo0+AppnWZj7CvjCKI4d/R8nXqiwdYaPWz76OPFjs6NoUMnNK2BVsZuD+D UCP3Wv6yy/0SnPvq+AkYZrD+jWlzs8UCVe8RfIetTQOyPpXNc16gfnn7/JC3cYwH60q0 33ZUS5CsUk3B1LYH9bLok0YXTGVGlf1tZFgvhEsoYV1xPo8i+IEl26w6BugdjD3NO+iy WWlKYp8t3YKBxpNwGbs9zq5Gb3EE3O4gHA1jC9XyyNKC/pEyPC6V5H2LaW49T9PR83hj Uikw== X-Gm-Message-State: AKS2vOy1ECoraICIQQmtmhMiftIOrJy0t8PIkrsWt2ORuDsqVBELTBVp irBU1EIfx/Jv5ZnHeMM= X-Received: by 10.28.158.206 with SMTP id h197mr7123797wme.110.1497640540815; Fri, 16 Jun 2017 12:15:40 -0700 (PDT) Received: from [192.168.1.19] (ARennes-656-1-267-63.w90-32.abo.wanadoo.fr. [90.32.171.63]) by smtp.googlemail.com with ESMTPSA id 22sm3635592wrt.36.2017.06.16.12.15.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 12:15:40 -0700 (PDT) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: Eli Zaretskii References: <84r2ykc9fa.fsf@gmail.com> <83y3srzske.fsf@gnu.org> From: =?UTF-8?Q?Vincent_Bela=c3=afche?= Message-ID: Date: Fri, 16 Jun 2017 21:15:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <83y3srzske.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 à 20:38, Eli Zaretskii a écrit : >> From: vincent.belaiche@gmail.com (Vincent Belaïche) >> Cc: Vincent Belaïche >> Date: Fri, 16 Jun 2017 16:08:09 +0200 >> >> Attached is the file causing the issue. Recipe is just to visit the file >> with emacs -q, and you see that the encoding is not taken. > Your fancy comment causes this: remove the leading '[' and the problem > goes away. Looks like regex-quoting that somehow misfires. After some investigation, it seems that the bug is in regexp-quote: (regexp-quote "[comment]: # (") outputs "^\\[comment]: # ( " instead of "^\\[comment\\]: # ( " Vincent. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 15:31:33 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 19:31:34 +0000 Received: from localhost ([127.0.0.1]:51704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwxx-0003B0-Nx for submit@debbugs.gnu.org; Fri, 16 Jun 2017 15:31:33 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:36823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLwxw-0003Ar-Jk for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 15:31:33 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3wq9Tv2by8z1qvBP; Fri, 16 Jun 2017 21:31:31 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3wq9Tt13BVz3jR9w; Fri, 16 Jun 2017 21:31:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id qXMNGlpu4ZLl; Fri, 16 Jun 2017 21:31:29 +0200 (CEST) X-Auth-Info: DfUenYLREY+EOSMx3bZXcnrfuqvjkND8AynG8XVPDIf7pztSzqJHEvD4g5y1Tfbj Received: from igel.home (ppp-88-217-27-189.dynamic.mnet-online.de [88.217.27.189]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 16 Jun 2017 21:31:29 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id BBC562C3C79; Fri, 16 Jun 2017 21:31:28 +0200 (CEST) From: Andreas Schwab To: Vincent =?utf-8?Q?Bela=C3=AFche?= Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file References: <84r2ykc9fa.fsf@gmail.com> <83y3srzske.fsf@gnu.org> X-Yow: Now I can join WEIGHT WATCHERS! Date: Fri, 16 Jun 2017 21:31:28 +0200 In-Reply-To: ("Vincent =?utf-8?Q?Bela=C3=AFche=22's?= message of "Fri, 16 Jun 2017 21:15:37 +0200") Message-ID: <87mv97n2zz.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 27391 Cc: Eli Zaretskii , 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Jun 16 2017, Vincent Belaïche wrote: > After some investigation, it seems that the bug is in regexp-quote: > > (regexp-quote "[comment]: # (") > > outputs > > "^\\[comment]: # ( " > > instead of > > "^\\[comment\\]: # ( " But `]' is not special. (string-match "^\\[comment]: # ( " "[comment]: # ( ") => 0 Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 15:37:48 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 19:37:48 +0000 Received: from localhost ([127.0.0.1]:51714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLx3z-0003Jg-M1 for submit@debbugs.gnu.org; Fri, 16 Jun 2017 15:37:48 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLx3y-0003JV-Gi for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 15:37:46 -0400 Received: by mail-wm0-f53.google.com with SMTP id u195so19336744wmd.1 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 12:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cUT4wSLdZ2l9jgUGT/vVzysm4XVleiqvxfBVrxXSUUY=; b=NA/cy1odN4QZQUYF/G1G/kIoJyZImKMHPOBiKDSB1w9M3fYqLLInvctACz4IkFjkBJ c8gTNjt9rR7d21nIxe1MYNqSkAGZZF2lV4OWB28L3EVoiwLxCsO9Ht50kg+be3y6Tu0X kCdqJmLMuobjVwG0zL0DhdXvEwiK59z1aHqc/gW1a+3d/OOb7p4NMD2STe+o7aCzld6s lXrBE1v+/8CpUziKOMijR/uGZWLA/bprF8TxIIzyMXPqHWE64X8cPH2xPOJLtZgWQRQL HB/CP/X9hnZLBEpU/v3XH8504JD8l8SK1WxpPrH6UmkMWBRm35tk1sJkhDo+rlnl95/+ jvnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cUT4wSLdZ2l9jgUGT/vVzysm4XVleiqvxfBVrxXSUUY=; b=OG4S6gsYEmkFtTR4tn5aro1qnicxt+IFgFZITCxpGP8PsqQm1E9zzLgoFFfxQlybM/ TebomJCk34G4o4dwQmPcqHvSY6tUxVn6FMrWxAK3K/rPG5PRGf/xFkkiyIoXiITWysHx dd2gfgCPJ/vQ0Ea4pVcJurhTFQXTSQKKh+4MgbnHYWBsY8nDsph7PBXbGRF89uiRqCNW vVehyfbgco98ce+pS0u/g5bNsbO+MS/+5rWA4HxTL4EOhYYL+zd2tVYcSS1FYmdqJ2Dv 0NwmgEPVFByRaNVONIOQs5y6GzCV9wYtvmLKpjfwO5RnF9PDcABTcAxJUeLVtGVM0bQg oWUA== X-Gm-Message-State: AKS2vOwXAIjo6vhDoiVAA3nxBwPxxBAOev203T3Z0T7dZA4BqebtefM7 snlxLm4WQl+gelWUusI= X-Received: by 10.28.92.13 with SMTP id q13mr8483905wmb.20.1497641860614; Fri, 16 Jun 2017 12:37:40 -0700 (PDT) Received: from [192.168.1.19] (ARennes-656-1-267-63.w90-32.abo.wanadoo.fr. [90.32.171.63]) by smtp.googlemail.com with ESMTPSA id y17sm3834700wrb.39.2017.06.16.12.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 12:37:40 -0700 (PDT) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: Eli Zaretskii References: <84r2ykc9fa.fsf@gmail.com> <83y3srzske.fsf@gnu.org> From: =?UTF-8?Q?Vincent_Bela=c3=afche?= Message-ID: <238fb785-932e-f0a5-e2dd-c9e199716efb@gmail.com> Date: Fri, 16 Jun 2017 21:37:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: 27391@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 à 21:15, Vincent Belaïche a écrit : > > > Le 16/06/2017 à 20:38, Eli Zaretskii a écrit : >>> From: vincent.belaiche@gmail.com (Vincent Belaïche) >>> Cc: Vincent Belaïche >>> Date: Fri, 16 Jun 2017 16:08:09 +0200 >>> >>> Attached is the file causing the issue. Recipe is just to visit the >>> file >>> with emacs -q, and you see that the encoding is not taken. >> Your fancy comment causes this: remove the leading '[' and the problem >> goes away. Looks like regex-quoting that somehow misfires. > > After some investigation, it seems that the bug is in regexp-quote: > > (regexp-quote "[comment]: # (") > > outputs > > "^\\[comment]: # ( " > > instead of > > "^\\[comment\\]: # ( " > > > Vincent. > > 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. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 17:27:39 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 21:27:39 +0000 Received: from localhost ([127.0.0.1]:51753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLymJ-00063B-BF for submit@debbugs.gnu.org; Fri, 16 Jun 2017 17:27:39 -0400 Received: from smtp05.smtpout.orange.fr ([80.12.242.127]:31628 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLymH-00062v-UY for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 17:27:38 -0400 Received: from AIGLEROYAL ([90.32.171.63]) by mwinf5d40 with ME id ZZTW1v00L1NRGYS03ZTWjG; Fri, 16 Jun 2017 23:27:31 +0200 X-ME-Helo: AIGLEROYAL X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Fri, 16 Jun 2017 23:27:31 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: Eli Zaretskii , 27391@debbugs.gnu.org Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Fri, 16 Jun 2017 23:27:27 +0200 Message-ID: <84zid7y668.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 =E0 21:37, Vincent Bela=EFche a =E9crit : > > > Le 16/06/2017 =E0 21:15, Vincent Bela=EFche a =E9crit : >> [...] >> >> > 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. --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 17:34:44 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 21:34:44 +0000 Received: from localhost ([127.0.0.1]:51761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLytA-0006Gu-4k for submit@debbugs.gnu.org; Fri, 16 Jun 2017 17:34:44 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:36447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLyt8-0006Ge-QZ for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 17:34:43 -0400 Received: by mail-oi0-f44.google.com with SMTP id k145so30774019oih.3 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 14:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iHh7L4mO9m1ExY9TmVVfe11t1erJ+RFvlfwxePjE3B4=; b=pYBxpDgN+hgAPBGmVmbdCzyOHGmW5i6LqGRIo5Wacg7NAOsZG9UsTCPAJssSfOneBS rpRvWGNjrrT5Zhsd+XqN8BtnQ4qNVdNDOZsBtZS3kkDs63licqCGEKAhd6HocFv7oZWh Mslq7TRNY5ZGktOx2izxhcWeKgFq/x68TY0S52hNxZRfWFDZQiBg1pkzlk4NGWXxWmrs FSct/tPlEQvzlyZInrn+bnNJwjaxRjj6ZkGfXILT/V0q+OENwGYoohunlTvat97y7lgj /yeJOKcmgOQcrcashm8fiiDucR/O0Tl6ReQW2LdsdnA3TDYP+iEibTz+j3R5r1llmzQZ we7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iHh7L4mO9m1ExY9TmVVfe11t1erJ+RFvlfwxePjE3B4=; b=NkWpF5h9hpV8DV2PMzU0SosdT0gJELk9tL1EwFf6EguXf4BpJHkiigDwTSfFUGtfSo R3kpR+L2gmnaDKyIx6Q9q3d4hLbb0zhRCju6qOLJsBU4ciaVgDFvZD39M4gNHHjlclWp pla96iyjZFtEsBv9aUmE2E9pPv2gVxobXYhQ8uRWI5QfvAsYxnsYev546/bdg1Knc//f gI0Ea3VNzEVsu3Mxh4NF6U7oOHtmv+empmsprTWrw+0nzcPZINqLrdDr1FQyDLCAqgxD OqJG9qtqn7gguMfGkOvBJRt66GsIUTLUJhCPId7hq91HFIn7M+lxjn2eSANrB9mz94ty ZRzg== X-Gm-Message-State: AKS2vOxgQ8EdVINYvwZhVqi9lbetuf3APLfWnEzkIMQ526RF7+4jEb+I MwAVUggbo/d9JO7tih9ElAceZR3qEA== X-Received: by 10.202.235.12 with SMTP id j12mr6370606oih.2.1497648877035; Fri, 16 Jun 2017 14:34:37 -0700 (PDT) MIME-Version: 1.0 References: <841sqkdzh5.fsf@gmail.com> <84zid7y668.fsf@gmail.com> In-Reply-To: <84zid7y668.fsf@gmail.com> From: Philipp Stephani Date: Fri, 16 Jun 2017 21:34:26 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113cc70c50656905521a8d33" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113cc70c50656905521a8d33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Bela=C3=AFche schrieb am Fr., 16. Juni= 2017 um 23:28 Uhr: > > > Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : > > > > > > Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : > >> > > [...] > > >> > >> > > 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]")) --001a113cc70c50656905521a8d33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Vincen= t Bela=C3=AFche <vincent.b= elaiche@gmail.com> schrieb am Fr., 16. Juni 2017 um 23:28=C2=A0Uhr:<= br>


Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>
>
> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit :
>>

[...]

>>
>>
> 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 int= o.

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 ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (looking-at re-coding) "ok" "nak&= quot;))))

I tried it with point at end of line

[comment]: # ( Local Variables: )

and it answered "ok". Now I defined this with re-search-forward i= nstead
of looking-at:

(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (re-search-forward re-coding nil t) "ok&quo= t; "nak"))))

I placed the point before the coding: line, and I also got answer "ok&= quot;

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...

=C2=A0 Vincent.


I think it's actually the regexp that = searches for "Local Variables". The following minimal example fai= ls for me:

(with-temp-buffer
=C2=A0= (insert "

[comment]: # ( Local Variables: )<= /div>
[comment]: # ( coding: utf-8 )
[comment]: # ( End: )

")
(goto-char (point-min))
(re-search-forward
=C2=A0"[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^= \r\n]*\\)[\r\n]"))

--001a113cc70c50656905521a8d33-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 17:40:17 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 21:40:17 +0000 Received: from localhost ([127.0.0.1]:51766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLyyW-0006QF-TZ for submit@debbugs.gnu.org; Fri, 16 Jun 2017 17:40:17 -0400 Received: from mail-ot0-f178.google.com ([74.125.82.178]:35780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLyyV-0006Q1-JZ for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 17:40:16 -0400 Received: by mail-ot0-f178.google.com with SMTP id u13so24168086otd.2 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 14:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DXE0b1QZ/um0C+dX5ngsSxowBYo+uutI0jmbb5XQ4UU=; b=lx7+QoGV1Vr/86FhNNWX3rj+B6OVXIRsHj2uWEndUOa8UbkvuwrHSlmByO7V6AeANp 9VKalEN9V/c9bNfyYz5ANNjKrDIqX2KPHZG/64bYIbTLUTnLnRWIhgQaXdroc2j+/XEl 1GrAOCrHHizOwX1VPaRTpq+981q8Yw9vLHXegBwwBu4roaUY6E1sdKvGlB5JRByoCNEz txNnkZ+/CuGckNVUO7em2EeoJpa4M41Q02yTcfDWkO/sfwFu/2ti/qcy/nsjd6NMaiYC XPj1tZhBGwwfbwv9fpGlXtnduWokZvD3yG8Nk2ytQo+gyFsGhl+lyBGktYlM26+bt1va gCfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DXE0b1QZ/um0C+dX5ngsSxowBYo+uutI0jmbb5XQ4UU=; b=uFeryB5Ji7HKOc8lHvmFhtwUwKI1+bhWXD+BI/iY9SydM5Y0AT5ZEaZLaUy7dANyBz iaCiOI2v/ygHoPhZhmoDR23gcqw4HeQJnAMjx/67VzoE01mi7KSkIMRsowlnIUx8pSK/ YZ0btdQdBz0WZ0EgHyjrxZFoHClL0ok3npRFWB4fakhVmGrGGeCBJk1h8hw+BMoWn77r 1T1sYSMxqiQIEEaqd16PJOvg9sme8/Wne/dSaUFE3PVzo3jBYjyJZFuZ3DCEGRvbelM2 xpS/4D1yWae2CSFkA/C4ZV//NsjCDDE50MyGHfm9b23XXQBsuDIcMh/H2ewUgdTKMhBq AFEg== X-Gm-Message-State: AKS2vOxSe83EgqSyTRXFmyoU3xye+aufmvj6vj0Ivfm7o3w8faljqnnM FqTSm14H9IsMeKg/8nUkY+DbWdBjBA== X-Received: by 10.157.43.199 with SMTP id u65mr7941947ota.182.1497649209811; Fri, 16 Jun 2017 14:40:09 -0700 (PDT) MIME-Version: 1.0 References: <841sqkdzh5.fsf@gmail.com> <84zid7y668.fsf@gmail.com> In-Reply-To: From: Philipp Stephani Date: Fri, 16 Jun 2017 21:39:59 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113cffd2262c1f05521aa1ba" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a113cffd2262c1f05521aa1ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philipp Stephani schrieb am Fr., 16. Juni 2017 um 23:34 Uhr: > Vincent Bela=C3=AFche schrieb am Fr., 16. Ju= ni > 2017 um 23:28 Uhr: > >> >> >> Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : >> > >> > >> > Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : >> >> >> >> [...] >> >> >> >> >> >> > 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 int= o. >> >> 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 [. --001a113cffd2262c1f05521aa1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 16. Juni 2017 um 23:34=C2=A0Uhr:
Vincent Bela=C3=AFche <vincent.belaiche@gmail.com> schrieb am Fr.= , 16. Juni 2017 um 23:28=C2=A0Uhr:
=

Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>
>
> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit :
>>

[...]

>>
>>
> 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 int= o.

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 ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (looking-at re-coding) "ok" "nak&= quot;))))

I tried it with point at end of line

[comment]: # ( Local Variables: )

and it answered "ok". Now I defined this with re-search-forward i= nstead
of looking-at:

(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (re-search-forward re-coding nil t) "ok&quo= t; "nak"))))

I placed the point before the coding: line, and I also got answer "ok&= quot;

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...

=C2=A0 Vincent.


I think it's actually the regexp that searches for "= Local Variables". The following minimal example fails for me:

(with-temp-buffer
=C2=A0 (insert "
<= br>
[comment]: # ( Local Variables: )
[comment]: # ( coding: ut= f-8 )
[comment]: # ( End: )
<= div>
")
(goto-char (point-min))
(re-= search-forward
=C2=A0"[\r\n]\\([^[\r\n]*\\)[ \t]*Local Varia= bles:[ \t]*\\([^\r\n]*\\)[\r\n]"))


Does anybody know why the second charac= ter range says [^[\r\n] instead of =C2=A0[^\r\n]? This seems to explicitly = exclude a leading [.
--001a113cffd2262c1f05521aa1ba-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 17:52:43 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 21:52:43 +0000 Received: from localhost ([127.0.0.1]:51771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzAZ-0006lp-7V for submit@debbugs.gnu.org; Fri, 16 Jun 2017 17:52:43 -0400 Received: from mail-ot0-f171.google.com ([74.125.82.171]:35265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzAX-0006lb-A2 for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 17:52:41 -0400 Received: by mail-ot0-f171.google.com with SMTP id u13so24315115otd.2 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 14:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rqGbh2mf7l16edAyjoitwUukKrcYGjsGG4w0LL0dVHc=; b=Ob7F8coYuC9g9iLKpU3nrBM3wvJL6Wyl3RJMxfkTFQSPK2zmMe/VAKDhZDNAKGs9iI ZVXGc4jUwyvweYh/x4GJt547ID8/8CcvHCWENAfXauvlvPdbUAj94ggYuXj7hliTvK3B ilcjzWb/lsHUGbwCpBtHIB/HXIDgeLolTV4cq5rnPuw1GWkAYdCXiMW2rqvdKg13ip2k XxjNQHUHHnnnaQPKJxuoTCkyemXEypfTpgZwbyGefDwG4GctCmJ+YbKK72h6tS5vkpG+ xQl1KPZYINeY8U5+ps0eTV6SYP80VRwwYGyvgzhNhdCFCJyWXTv3wXnM8nYEPkcOGwuK 6Ucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rqGbh2mf7l16edAyjoitwUukKrcYGjsGG4w0LL0dVHc=; b=mu7NwYvUelnRV4k4ho6d+VjA8ttRDOh2NOmEw5EiyciBS+P3PWI/OxKRMkJEccMvln PR5m1HmHUI3LN2w3pZsLreJMdg65BVCODd2s+qA2JmmqKjNZ/zs4JaCXzBJWdLu+fFll RGB2BXsDq8+af8/wRp1uvlQWUlKIRcN/h/ma0PFnCsC+UwQ4CPRaWvR/t871QRKSV/OT 3qEdYCdVtwW8EeKGbKY4fLs6mfoLslylLtwfyAuKQtOHAtS3E70DqegVpTLpdHrpzz/X Tq+Z7Cj6TIxXnvHy6BXd5L3RVY+JV1SfBJDZ08suduKA4yMeGKrIW0VaXW8YiwneUn3+ PMVg== X-Gm-Message-State: AKS2vOxFPPTreiJRmyRRtlIwWkHlUYBWaUa1RnAa1rt74By/cJboUi2w KqAYNG8wZPtjCgOxrQlKVtpOfuri2w== X-Received: by 10.157.16.8 with SMTP id h8mr7811224ote.80.1497649955650; Fri, 16 Jun 2017 14:52:35 -0700 (PDT) MIME-Version: 1.0 References: <841sqkdzh5.fsf@gmail.com> <84zid7y668.fsf@gmail.com> In-Reply-To: From: Philipp Stephani Date: Fri, 16 Jun 2017 21:52:24 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Content-Type: multipart/mixed; boundary="001a11407a7a9adeac05521acd33" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a11407a7a9adeac05521acd33 Content-Type: multipart/alternative; boundary="001a11407a7a9adea905521acd31" --001a11407a7a9adea905521acd31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philipp Stephani schrieb am Fr., 16. Juni 2017 um 23:39 Uhr: > Philipp Stephani schrieb am Fr., 16. Juni 2017 um > 23:34 Uhr: > >> Vincent Bela=C3=AFche schrieb am Fr., 16. J= uni >> 2017 um 23:28 Uhr: >> >>> >>> >>> Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : >>> > >>> > >>> > Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : >>> >> >>> >>> [...] >>> >>> >> >>> >> >>> > 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 set= s >>> > 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 som= e >>> 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". Th= e >> 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. --001a11407a7a9adea905521acd31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 16. Juni 2017 um 23:39=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 16. Juni 2017= um 23:34=C2=A0Uhr:
Vincent Bela=C3=AFche <vincent.belaic= he@gmail.com> schrieb am Fr., 16. Juni 2017 um 23:28=C2=A0Uhr:


Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>
>
> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit :
>>

[...]

>>
>>
> 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 int= o.

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 ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (looking-at re-coding) "ok" "nak&= quot;))))

I tried it with point at end of line

[comment]: # ( Local Variables: )

and it answered "ok". Now I defined this with re-search-forward i= nstead
of looking-at:

(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((prefix (regexp-quote "[comment]: # ("))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix (regexp-quote ")"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(re-coding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[\r\n]" prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; N.B. without the \n below, the = regexp can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; eat newlines.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[ \t]*coding[ \t]*:[ \t]*\\(= [^ \t\r\n]+\\)[ \t]*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suffix "[\r\n]")))
=C2=A0 =C2=A0 (message (if (re-search-forward re-coding nil t) "ok&quo= t; "nak"))))

I placed the point before the coding: line, and I also got answer "ok&= quot;

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...

=C2=A0 Vincent.


I think it's actually the regexp that searches for "= Local Variables". The following minimal example fails for me:

(with-temp-buffer
=C2=A0 (insert "
<= br>
[comment]: # ( Local Variables: )
[comment]: # ( coding: ut= f-8 )
[comment]: # ( End: )

")
=
(goto-char (point-min))
(re-search-forward
=C2=A0&= quot;[\r\n]\\([^[\r\n]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]&= quot;))


<= /div>
Does anybody kn= ow why the second character range says [^[\r\n] instead of =C2=A0[^\r\n]? T= his seems to explicitly exclude a leading [.
=

If this is a typo, then here's a patch.=C2=A0
=
--001a11407a7a9adea905521acd31-- --001a11407a7a9adeac05521acd33 Content-Type: text/plain; charset="US-ASCII"; name="0001-Allow-local-variables-section-to-begin-with-a-square-b.txt" Content-Disposition: attachment; filename="0001-Allow-local-variables-section-to-begin-with-a-square-b.txt" Content-Transfer-Encoding: base64 Content-ID: <15cb2e48903d80038a11> X-Attachment-Id: 15cb2e48903d80038a11 RnJvbSAyZjhiYmY3ZTcyOWVhMDlhZGRmMGQwNjY4NjFhM2IzOGMzMTIxNDFkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IEZyaSwgMTYgSnVuIDIwMTcgMjM6NDk6MDkgKzAyMDAKU3ViamVjdDogW1BBVENIXSBBbGxv dyBsb2NhbCB2YXJpYWJsZXMgc2VjdGlvbiB0byBiZWdpbiB3aXRoIGEgc3F1YXJlIGJyYWNrZXQK CkZpeGVzIEJ1ZyMyNzM5MS4KCiogbGlzcC9pbnRlcm5hdGlvbmFsL211bGUuZWwgKGZpbmQtYXV0 by1jb2RpbmcpOiBGaXggcmVndWxhcgpleHByZXNzaW9uIGZvciAiTG9jYWwgVmFyaWFibGVzIiBz ZWN0aW9uLgoKKiB0ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLXRlc3RzLmVsIChmaW5kLWF1 dG8tY29kaW5nLS1idWcyNzM5MSk6CkFkZCB1bml0IHRlc3QuCi0tLQogbGlzcC9pbnRlcm5hdGlv bmFsL211bGUuZWwgICAgICAgICAgICB8ICAyICstCiB0ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9t dWxlLXRlc3RzLmVsIHwgMzkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDIg ZmlsZXMgY2hhbmdlZCwgNDAgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQogY3JlYXRlIG1v ZGUgMTAwNjQ0IHRlc3QvbGlzcC9pbnRlcm5hdGlvbmFsL211bGUtdGVzdHMuZWwKCmRpZmYgLS1n aXQgYS9saXNwL2ludGVybmF0aW9uYWwvbXVsZS5lbCBiL2xpc3AvaW50ZXJuYXRpb25hbC9tdWxl LmVsCmluZGV4IGZhM2FkODBlMmYuLjZjZmI3ZTZkNDUgMTAwNjQ0Ci0tLSBhL2xpc3AvaW50ZXJu YXRpb25hbC9tdWxlLmVsCisrKyBiL2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLmVsCkBAIC0xOTcw LDcgKzE5NzAsNyBAQCBmaW5kLWF1dG8tY29kaW5nCiAJICAoZ290by1jaGFyIHRhaWwtc3RhcnQp CiAJICAocmUtc2VhcmNoLWZvcndhcmQgIltcclxuXVxeTCIgdGFpbC1lbmQgdCkKIAkgIChpZiAo cmUtc2VhcmNoLWZvcndhcmQKLQkgICAgICAgIltcclxuXVxcKFteW1xyXG5dKlxcKVsgXHRdKkxv Y2FsIFZhcmlhYmxlczpbIFx0XSpcXChbXlxyXG5dKlxcKVtcclxuXSIKKwkgICAgICAgIltcclxu XVxcKFteXHJcbl0qXFwpWyBcdF0qTG9jYWwgVmFyaWFibGVzOlsgXHRdKlxcKFteXHJcbl0qXFwp W1xyXG5dIgogCSAgICAgICB0YWlsLWVuZCB0KQogCSAgICAgIDs7IFRoZSBwcmVmaXggaXMgd2hh dCBjb21lcyBiZWZvcmUgImxvY2FsIHZhcmlhYmxlczoiIGluIGl0cwogCSAgICAgIDs7IGxpbmUu ICBUaGUgc3VmZml4IGlzIHdoYXQgY29tZXMgYWZ0ZXIgImxvY2FsIHZhcmlhYmxlczoiCmRpZmYg LS1naXQgYS90ZXN0L2xpc3AvaW50ZXJuYXRpb25hbC9tdWxlLXRlc3RzLmVsIGIvdGVzdC9saXNw L2ludGVybmF0aW9uYWwvbXVsZS10ZXN0cy5lbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAw MDAwMDAwMDAwLi4wODRmNjA5YzQ1Ci0tLSAvZGV2L251bGwKKysrIGIvdGVzdC9saXNwL2ludGVy bmF0aW9uYWwvbXVsZS10ZXN0cy5lbApAQCAtMCwwICsxLDM5IEBACis7OzsgbXVsZS10ZXN0cy5l bCAtLS0gdW5pdCB0ZXN0cyBmb3IgbXVsZS5lbCAgICAgICAgIC0qLSBsZXhpY2FsLWJpbmRpbmc6 IHQ7IC0qLQorCis7OyBDb3B5cmlnaHQgKEMpIDIwMTcgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u LCBJbmMuCisKKzs7IFRoaXMgZmlsZSBpcyBwYXJ0IG9mIEdOVSBFbWFjcy4KKworOzsgR05VIEVt YWNzIGlzIGZyZWUgc29mdHdhcmU6IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2Rp ZnkKKzs7IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UgYXMgcHVibGlzaGVkIGJ5Cis7OyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBlaXRo ZXIgdmVyc2lvbiAzIG9mIHRoZSBMaWNlbnNlLCBvcgorOzsgKGF0IHlvdXIgb3B0aW9uKSBhbnkg bGF0ZXIgdmVyc2lvbi4KKworOzsgR05VIEVtYWNzIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCis7OyBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorOzsgTUVSQ0hBTlRBQklMSVRZIG9y IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorOzsgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKworOzsgWW91IHNob3VsZCBoYXZl IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKzs7IGFs b25nIHdpdGggR05VIEVtYWNzLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNl bnNlcy8+LgorCis7OzsgQ29tbWVudGFyeToKKworOzsgVW5pdCB0ZXN0cyBmb3IgbGlzcC9pbnRl cm5hdGlvbmFsL211bGUuZWwuCisKKzs7OyBDb2RlOgorCisoZXJ0LWRlZnRlc3QgZmluZC1hdXRv LWNvZGluZy0tYnVnMjczOTEgKCkKKyAgIkNoZWNrIHRoYXQgQnVnIzI3MzkxIGlzIGZpeGVkLiIK KyAgKHdpdGgtdGVtcC1idWZmZXIKKyAgICAoaW5zZXJ0ICJcbltjb21tZW50XTogIyAoIExvY2Fs IFZhcmlhYmxlczogKVxuIgorICAgICAgICAgICAgIltjb21tZW50XTogIyAoIGNvZGluZzogdXRm LTgJKVxuIgorICAgICAgICAgICAgIltjb21tZW50XTogIyAoIEVuZDoJCSluIikKKyAgICAoZ290 by1jaGFyIChwb2ludC1taW4pKQorICAgIChzaG91bGQgKGVxdWFsIChsZXQgKChhdXRvLWNvZGlu Zy1hbGlzdCAoKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAoYXV0by1jb2RpbmctcmVnZXhw LWFsaXN0ICgpKQorICAgICAgICAgICAgICAgICAgICAgICAgIChhdXRvLWNvZGluZy1mdW5jdGlv bnMgKCkpKQorICAgICAgICAgICAgICAgICAgICAgKGZpbmQtYXV0by1jb2RpbmcgIiIgKGJ1ZmZl ci1zaXplKSkpCisgICAgICAgICAgICAgICAgICAgJyh1dGYtOCAuIDpjb2RpbmcpKSkpKQorCis7 OzsgbXVsZS10ZXN0cy5lbCBlbmRzIGhlcmUKLS0gCjIuMTMuMQoK --001a11407a7a9adeac05521acd33-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 18:10:14 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 22:10:14 +0000 Received: from localhost ([127.0.0.1]:51787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzRW-0007GB-Ik for submit@debbugs.gnu.org; Fri, 16 Jun 2017 18:10:14 -0400 Received: from smtp05.smtpout.orange.fr ([80.12.242.127]:38531 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzRU-0007Fw-Jj for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 18:10:13 -0400 Received: from AigleRoyal ([90.32.171.63]) by mwinf5d40 with ME id ZaA51v00Q1NRGYS03aA5Bo; Sat, 17 Jun 2017 00:10:06 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Sat, 17 Jun 2017 00:10:06 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: Eli Zaretskii , 27391@debbugs.gnu.org Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Sat, 17 Jun 2017 00:09:56 +0200 Message-ID: <84y3sry47f.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 16/06/2017 =E0 21:37, Vincent Bela=EFche a =E9crit : > > > Le 16/06/2017 =E0 21:15, Vincent Bela=EFche a =E9crit : >> [...] >> >> > 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. --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 18:23:30 2017 Received: (at 27391) by debbugs.gnu.org; 16 Jun 2017 22:23:30 +0000 Received: from localhost ([127.0.0.1]:51797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzeM-0007dM-4D for submit@debbugs.gnu.org; Fri, 16 Jun 2017 18:23:30 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:36568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLzeK-0007d7-JH for 27391@debbugs.gnu.org; Fri, 16 Jun 2017 18:23:28 -0400 Received: by mail-wr0-f170.google.com with SMTP id 36so44750709wry.3 for <27391@debbugs.gnu.org>; Fri, 16 Jun 2017 15:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yl1qsS5V4AUaLC/YMKdaLEPiW2C1PTpnHMIlb9zzxjs=; b=eej7cVsqmNwAjA/p7DidWH21P8iwLRMf+QVtoE5CTt0SfVDX3HOM3X+8hnxPillMkK 6iESz4tSEDOSsEOkVpZ4XOdBqLav7CCyPKCGQCgIR9nsidwzFOMtMai0z2lvGrUSzvQY XFAl7xxPLsSw69B+qO52Ci+SioXsCFfmYDMN1ZmkN+M9rw5a0BPNLToAu6pwsauCyfsg 1w7ZOZ2hEVqJGYNvypgjmWcuXxTo6OJqoYhttzj20Oic5UWMiHYfoZINq3ix4dtlA6Um RxbIE+zNenW1YVb1La/NEXVomvUPPKJId2sISXxU9ujeiJgllWp+vPfTibNpvmQZU5EY E3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yl1qsS5V4AUaLC/YMKdaLEPiW2C1PTpnHMIlb9zzxjs=; b=iNpQPTnKTFBkFMKR/ENZat+b6ZE5UB70cT/ECrpQ+NSleXH/QJzYMYhvSzOngy42iv 3fTxaDrrv8xD2zBgLWRDNqJ18NudlNEEY93clgBFsUDeFNSva3B2xYtY7RHGY9pdV71O 3g3iSps+EoYEBYWA36jAIE4PDNdS0tAAWyajwAKCXikTg9oOqmgajkqLavugJofnR3UQ BvTBFSV11oW+RbfkocGTjbSqEZmbp7SOKxXtSFcMWxxhnpxHXaK+2MFkjkBUK/j1Is/c us0Go106PIbCndnOOdYEpwL0WU3jalNenOfbLFAPLnb5m1TJW6qKIfWKGE/csjYIYKJ/ lIbw== X-Gm-Message-State: AKS2vOz4ILBxv8u+nrMkTh1iakFJD+3lF06KJ1DFVHvWEVMUJLg2963H J4N7UFzXXUstQA== X-Received: by 10.223.173.140 with SMTP id w12mr8847735wrc.125.1497651802896; Fri, 16 Jun 2017 15:23:22 -0700 (PDT) Received: from [192.168.1.19] (ARennes-656-1-267-63.w90-32.abo.wanadoo.fr. [90.32.171.63]) by smtp.googlemail.com with ESMTPSA id g203sm5044468wmd.23.2017.06.16.15.23.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 15:23:22 -0700 (PDT) Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: Eli Zaretskii , 27391@debbugs.gnu.org, p.stephani2@gmail.com References: <84y3sry47f.fsf@gmail.com> From: =?UTF-8?Q?Vincent_Bela=c3=afche?= Message-ID: Date: Sat, 17 Jun 2017 00:23:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <84y3sry47f.fsf@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. Although I don't think that this is a good solution not to factorize code when possible. Factorizing makes it more maintainable. V. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 01:45:46 2017 Received: (at 27391) by debbugs.gnu.org; 17 Jun 2017 05:45:46 +0000 Received: from localhost ([127.0.0.1]:51949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM6YM-0006qc-7T for submit@debbugs.gnu.org; Sat, 17 Jun 2017 01:45:46 -0400 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:19543 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM6YK-0006qL-9n for 27391@debbugs.gnu.org; Sat, 17 Jun 2017 01:45:44 -0400 Received: from AigleRoyal ([90.32.171.63]) by mwinf5d03 with ME id ZhlZ1v0091NRGYS03hlZTu; Sat, 17 Jun 2017 07:45:37 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Sat, 17 Jun 2017 07:45:37 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: Eli Zaretskii , 27391@debbugs.gnu.org, p.stephani2@gmail.com Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file In-Reply-To: Date: Sat, 17 Jun 2017 07:45:35 +0200 Message-ID: <84wp8bxj40.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170616-2, 16/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 27391 Cc: =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Le 17/06/2017 =E0 00:23, Vincent Bela=EFche a =E9crit : > > > Le 17/06/2017 =E0 00:09, Vincent Bela=EFche a =E9crit : >> >> Le 16/06/2017 =E0 21:37, Vincent Bela=EFche a =E9crit : >>> >>> Le 16/06/2017 =E0 21:15, Vincent Bela=EFche a =E9crit : >> [...] >> >>>> >>> 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= =2E >> 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. Although I > don't think that this is a good solution not to factorize code when > possible. Factorizing makes it more maintainable. > > V. Just to mention the following points noted by me when comparing the code in find-auto-coding and in hack-local-variables: * In hack-local-variables the tailing local variables section is considered to be at max 3000 characters from eob, while in find-auto-coding it is considered to be 3072. The =AB correct =BB figure should be 3072, not 3000, for consistency with =AB 1024 * 3 =BB code in function Finsert_file_contents of fileio.c : if (nread =3D=3D 1024) { int ntail; if (lseek (fd, - (1024 * 3), SEEK_END) < 0) report_file_error ("Setting file position", orig_filename); ntail =3D emacs_read_quit (fd, read_buf + nread, 1024 * 3); nread =3D ntail < 0 ? ntail : nread + ntail; } Maybe the exact value should be in some constant. * In find-auto-coding there is no such thing as regexp operator "^" (for bol) or "$" (for eol) used, instead there is "[\r\n]". I suspect that this is because at this stage the coding system is not yet set, and therefore there is no such thing as bol or eol, the whole buffer is a single line. If as such, I withdraw my previous statement that code factorization is desirable. * In both cases what is sought for is the *FIRST* occurrence searched *FORWARD* of case sensitive string "Local Variables:" in the buffer tailing 3000--3072 characters. I think that this is a problem and that either we should search it *BACKWARD* or after finding the 1st occurrence, possible subsequent occurrences should be searched for, and the last occurrence should be considered instead. I say this because with emacs-template package it is possible that the template file has some local variables in the template definition section that differ from that of template itself. See (info "(template) DefSect") For instance the end of the template file would be as follow: --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- =2E.. blah blah blah template content ... // Local Variables: // toto: "tata" // End: >>>TEMPLATE-DEFINITION-SECTION<<< =2E.. blah blah blah Lisp Template rules ... ;; Local Variables: ;; foo: "bar" ;; End: --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- Maybe preventing the [ character in the prefix string is not a typo but was some intentional design to allow preventing false detection of the local variable section. I strongly recommend that before doing any fix, somebody dig in file history to find when and *WHY* this [ preventing has been introduced --- sorry, but I do not volunteer for this tedious/time consuming kind of work... Vincent. --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 10:15:46 2017 Received: (at 27391-done) by debbugs.gnu.org; 17 Jun 2017 14:15:46 +0000 Received: from localhost ([127.0.0.1]:53486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEVu-0003yJ-GB for submit@debbugs.gnu.org; Sat, 17 Jun 2017 10:15:46 -0400 Received: from mail-ot0-f171.google.com ([74.125.82.171]:33246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEVs-0003y4-4E for 27391-done@debbugs.gnu.org; Sat, 17 Jun 2017 10:15:44 -0400 Received: by mail-ot0-f171.google.com with SMTP id y47so23556366oty.0 for <27391-done@debbugs.gnu.org>; Sat, 17 Jun 2017 07:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Wu5JaC9yh9NPV0OQOD/lqNi0Rxagrc34/LPkUhqxSi4=; b=dEyHf8w20B17ATurZ4VrhMcXoLPHBcwLqcOeHtFRO2ZoEiT6blSKUpg+5Rur/Hfp33 QFqUkvDiB3pvEAOYn3H7jBsU5fGPTiA4xUVnTu4EzT+fU8ryjPiTSu5Z8WKycsBSwaTS QXv5+gZKK6BLbAUYP6vI5oAL91TgFJi9LN5iJX9MkLq93NZXisPT1Hj6nhqGn4tlW+T2 r7GX+tm+n3VtQ1YYpNGTi7MCTcVmkicxJ5jy4DcAV/+MX5vQbVeRY4z00xkBWewG/IfI XP5vtw4+ATB9mXkOXuxZi3uPRnT2kVbBi/U6nHpLYSyaWnqUjfw6jwEcpPIc0IOELgvM 7mxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Wu5JaC9yh9NPV0OQOD/lqNi0Rxagrc34/LPkUhqxSi4=; b=LDp8pBd/jL9l02+2R159u3DrYYLf0L0M6JvXj3I2cUjPkmAWG6HeCsjzl+2X5Ky3OW hWU6RMEy7thpFFKaaHTY2pklX8yhuf0Q8jyCc32D8vCpgs/VLhz6eH59eK5xdIQrcA0f ngxb1ZBAFRteNUDAKHX7RnvZAh4Twlw24OQV7S4mhYSCN8uWnHkLW56JWETNdNM3YlPK zEuFlzUC6r3v5wWgr7wo+YdCYMs4xjTqrYCPIgS2LIYpGGqUq6DFSGqg0CznxNXtm/jC 4mxqo69WZ6no5AOguvJIVAW0ud9AuCyszoCfX3Pi2kPWhtm719q5kPk1Jz+/z9wHmxcF mHLQ== X-Gm-Message-State: AKS2vOzuML2Xx0k+AoN8u1QsgG/1YnixiQvqfQBVRhxoiPqXKvQy6cmA Lt3h9L6MeVZ0YfC4ML5JKK1EoB9Obg== X-Received: by 10.157.43.199 with SMTP id u65mr9511357ota.182.1497708938454; Sat, 17 Jun 2017 07:15:38 -0700 (PDT) MIME-Version: 1.0 References: <84y3sry47f.fsf@gmail.com> In-Reply-To: From: Philipp Stephani Date: Sat, 17 Jun 2017 14:15:27 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , Eli Zaretskii , 27391-done@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113cffd240ebc805522889f8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27391-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a113cffd240ebc805522889f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Bela=C3=AFche schrieb am Sa., 17. Juni= 2017 um 00:23 Uhr: > > > Le 17/06/2017 =C3=A0 00:09, Vincent Bela=C3=AFche a =C3=A9crit : > > > > Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit : > >> > >> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : > > [...] > > > >>> > >> 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 int= o. > > 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. --001a113cffd240ebc805522889f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Vincen= t Bela=C3=AFche <vincent.b= elaiche@gmail.com> schrieb am Sa., 17. Juni 2017 um 00:23=C2=A0Uhr:<= br>


Le 17/06/2017 =C3=A0 00:09, Vincent Bela=C3=AFche a =C3=A9crit :
>
> Le 16/06/2017 =C3=A0 21:37, Vincent Bela=C3=AFche a =C3=A9crit :
>>
>> Le 16/06/2017 =C3=A0 21:15, Vincent Bela=C3=AFche a =C3=A9crit : > [...]
>
>>>
>> 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: >
>=C2=A0 =C2=A0(re-search-forward
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "[\r\n]\\([^[\r\n= ]*\\)[ \t]*Local Variables:[ \t]*\\([^\r\n]*\\)[\r\n]"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 factorizatio= n
> of local variable parsing between mule.el and file.el. A better, more<= br> > 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.
>
>=C2=A0 =C2=A0 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 c3813b2aa8d2f5a6= 25195fdbbfe6a01a602d7735.
=C2=A0
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 plac= e 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.=C2=A0
--001a113cffd240ebc805522889f8-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 10:31:08 2017 Received: (at 27391) by debbugs.gnu.org; 17 Jun 2017 14:31:08 +0000 Received: from localhost ([127.0.0.1]:53496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEkm-0004Ks-14 for submit@debbugs.gnu.org; Sat, 17 Jun 2017 10:31:08 -0400 Received: from mail-ot0-f181.google.com ([74.125.82.181]:34768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMEkk-0004KP-5X for 27391@debbugs.gnu.org; Sat, 17 Jun 2017 10:31:06 -0400 Received: by mail-ot0-f181.google.com with SMTP id r67so46050795ota.1 for <27391@debbugs.gnu.org>; Sat, 17 Jun 2017 07:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NZTV0niuO4jAUYPQYBQGnzWXrYjQt6W+T1hZyl1rx7I=; b=I19JVh6PXY/Wi/bAO2OZG7YO2f2OpA3DpXKdgyk4L3TeAhFLsTfC+QISuFLepaH+9k Mj9O9r4lBHvD98SgeT1rV1HOZ2P7ZuIAVb5uHmFR0GJKJwm8LU0v6yHic1AGvcv9KlYM TAeYoJrYhJ3gal4Ca36amz2oHIUBmDteG0GJQ8Cu1yUxQ87gVDC6K1IOD3XBY3kk19GG IL+KRE5hCuPpkWMl7CFdhMOiqr5rgj2JXdUp6yf/4d5x1Q96lvHJS/TVcby9cKUHuKbg 6N4O49/X2FJZ2Du9c/XUc6vvnvvnTR5/wK3Kmfx/fvIQLIYqAcGRZvAAjFLJWmo98oRj NE4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NZTV0niuO4jAUYPQYBQGnzWXrYjQt6W+T1hZyl1rx7I=; b=XAWaleL6mU7mpmTcDfXHuvo5a2wTFyLB3jfoaKBjrHEQEyqIIduagxeyygb69gqIJD FfDBZLkNVYDrwbe5jfb3SW2iI0K4MZwbD6URXjuAw/Wgot12NaJ77uL1kJ3+7p6Jmxhp ICZnwy0HlxFcKNQm4zINnKGIHbuVq6oRJ9dfea1IRf8RJNKKHY4CcT0n9uRbRNxRzmAB t9x0cfVk7dwJxEUo9eo27LilKVFfK/tpuUuOlHiz0NEPu3pJqCAeVXPcj48CThwt3/FI TgT/hbFgXiCAqjOzqArB4HFhAzUba8Y312AyDma46kfOD/crzRU2eUrD7VrqG8+qo62c /fSw== X-Gm-Message-State: AKS2vOzvBmBLAsSJRv9ym3JdpRKgoALEu9gUk62nmLeMCvz9MUCLUTkB lARBWSRmomlLwL47xK3OGjqaFV0iEw== X-Received: by 10.157.14.8 with SMTP id c8mr4112750otc.19.1497709859483; Sat, 17 Jun 2017 07:30:59 -0700 (PDT) MIME-Version: 1.0 References: <84wp8bxj40.fsf@gmail.com> In-Reply-To: <84wp8bxj40.fsf@gmail.com> From: Philipp Stephani Date: Sat, 17 Jun 2017 14:30:49 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113d1cf426b494055228c0f6" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27391 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a113d1cf426b494055228c0f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Bela=C3=AFche schrieb am Sa., 17. Juni= 2017 um 07:45 Uhr: > > > Le 17/06/2017 =C3=A0 00:23, Vincent Bela=C3=AFche a =C3=A9crit : > > > > > * In find-auto-coding there is no such thing as regexp operator "^" (for > bol) or "$" (for eol) used, instead there is "[\r\n]". I suspect that > this is because at this stage the coding system is not yet set, and > therefore there is no such thing as bol or eol, the whole buffer is a > single line. If as such, I withdraw my previous statement that code > factorization is desirable. > Why? It's a small variant that should be distinguishable using a parameter to a shared function, such as: enum file_local_flags { file_local_flag_default =3D 0x0, file_local_flag_use_bol_eol =3D 0x1, file_local_flag_search_trailer =3D 0x2, }; Lisp_Object get_file_local_variable_value (Lisp_Object name, enum file_local_flags flags); > > > * In both cases what is sought for is the *FIRST* occurrence searched > *FORWARD* of case sensitive string "Local Variables:" in the buffer > tailing 3000--3072 characters. I think that this is a problem and that > either we should search it *BACKWARD* or after finding the 1st > occurrence, possible subsequent occurrences should be searched for, > and the last occurrence should be considered instead. > Yes, that would be consistent with normal file-local variables. > > Maybe preventing the [ character in the prefix string is not a typo > but was some intentional design to allow preventing false detection of > the local variable section. I strongly recommend that before doing any > fix, somebody dig in file history to find when and *WHY* this [ > preventing has been introduced --- sorry, but I do not volunteer for > this tedious/time consuming kind of work... > > With git-blame it's not really tedious. Commit 6b61353c0a0320ee15bb6488149735381fed62ec replaced ^\\(.*\\)[ \t]* with [\r\n]\\([^[\r\n]*\\)[ \t]*, so I think it's almost certain this is a typo (the previous regex didn't exclude the [ either). Anyway, if people want this to stay, they should have added a comment. --001a113d1cf426b494055228c0f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Vincen= t Bela=C3=AFche <vincent.b= elaiche@gmail.com> schrieb am Sa., 17. Juni 2017 um 07:45=C2=A0Uhr:<= br>


Le 17/06/2017 =C3=A0 00:23, Vincent Bela=C3=AFche a =C3=A9crit :
>
>
* In find-auto-coding there is no such thing as regexp operator "^&quo= t; (for
=C2=A0 bol) or "$" (for eol) used, instead there is "[\r\n]&= quot;. I suspect that
=C2=A0 this is because at this stage the coding system is not yet set, and<= br> =C2=A0 therefore there is no such thing as bol or eol, the whole buffer is = a
=C2=A0 single line. If as such, I withdraw my previous statement that code<= br> =C2=A0 factorization is desirable.

Why?= It's a small variant that should be distinguishable using a parameter = to a shared function, such as:

enum file_local_fla= gs {
=C2=A0 file_local_flag_default =3D 0x0,
=C2=A0 fil= e_local_flag_use_bol_eol =3D 0x1,
=C2=A0 file_local_flag_search_t= railer =3D 0x2,
};
Lisp_Object get_file_local_variable_= value (Lisp_Object name, enum file_local_flags flags);
=C2=A0


* In both cases what is sought for is the *FIRST* occurrence searched
=C2=A0 *FORWARD* of case sensitive string "Local Variables:" in t= he buffer
=C2=A0 tailing 3000--3072 characters. I think that this is a problem and th= at
=C2=A0 either we should search it *BACKWARD* or after finding the 1st
=C2=A0 occurrence, possible subsequent occurrences should be searched for,<= br> =C2=A0 and the last occurrence should be considered instead.

Yes, that would be consistent with normal file-local= variables.
=C2=A0

=C2=A0 Maybe preventing the [ character in the prefix string is not a typo<= br> =C2=A0 but was some intentional design to allow preventing false detection = of
=C2=A0 the local variable section. I strongly recommend that before doing a= ny
=C2=A0 fix, somebody dig in file history to find when and *WHY* this [
=C2=A0 preventing has been introduced --- sorry, but I do not volunteer for=
=C2=A0 this tedious/time consuming kind of work...


With git-blame it's not really ted= ious. Commit 6b61353c0a0320ee15bb6488149735381fed62ec replaced ^\\(.*\\)[ \= t]* with [\r\n]\\([^[\r\n]*\\)[ \t]*, so I think it's almost certain th= is is a typo (the previous regex didn't exclude the [ either). Anyway, = if people want this to stay, they should have added a comment.
<= /div> --001a113d1cf426b494055228c0f6-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 19 06:51:40 2017 Received: (at 27391) by debbugs.gnu.org; 19 Jun 2017 10:51:40 +0000 Received: from localhost ([127.0.0.1]:55649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMuHU-0003M6-Ex for submit@debbugs.gnu.org; Mon, 19 Jun 2017 06:51:40 -0400 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:18455 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMuHS-0003Ls-Th for 27391@debbugs.gnu.org; Mon, 19 Jun 2017 06:51:39 -0400 Received: from AigleRoyal ([90.32.171.63]) by mwinf5d55 with ME id aarU1v0051NRGYS03arUM1; Mon, 19 Jun 2017 12:51:32 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Mon, 19 Jun 2017 12:51:32 +0200 X-ME-IP: 90.32.171.63 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: Philipp Stephani , 27391@debbugs.gnu.org Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file In-Reply-To: Date: Mon, 19 Jun 2017 12:51:33 +0200 Message-ID: <84lgooxnbe.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170619-0, 19/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27391 Cc: Eli Zaretskii , =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) [...] > > With git-blame it's not really tedious. Commit > 6b61353c0a0320ee15bb6488149735381fed62ec replaced ^\\(.*\\)[ \t]* with > [\r\n]\\([^[\r\n]*\\)[ \t]*, so I think it's almost certain this is a > typo (the previous regex didn't exclude the [ either). Anyway, if > people want this to stay, they should have added a comment. Thank you, I had a look at Wikipedia for the QWERTY keyboard layout (I have a French keyboard and the layout is somehow different for \ and ]). Modern QWERTY layout is as follows: 1 2 3 4 5 6 7 8 9 0 - =3D Q W E R T Y U I O P [ ] \ A S D F G H J K L ; ' Z X C V B N M , . / So ] is just next to \. So, yes, definitely this is a typo, the author had too big a finger when hitting \. Concerning factorization, couldn't one use [\n\r] in all cases rather than a switch based on some input argument ? I was also wondering whether it is not possible to have a single regexp for the whole Local Variable section. The following `doit' function is a trial to do so. `M-x doit' will seach forward the whole Local Variables section and display "ok" if found, "nak" otherwise. (defun doit () (interactive) (let* ((eol "\\(\r\n?\\|\n\\)") (eol-again "\\1") (space-maybe "[ \t]*") ;; suffix may be the empty string (suffix "\\([^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\|\\)") (prefix "\\([ \t]*[^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\)") (prefix-again "\\2") (suffix-again "\\3") (symbol: "\\(?:\\(?:[^][()'\" \t\r\n]\\|\\\\[][()'\" \t]\\)+[ \t]*:\\)") (sexp (concat "\\(?:" (substring prefix 2)))) (message (if (and (re-search-forward (concat eol prefix space-maybe "Local Variables:" space-maybe suffix space-maybe e= ol-again "\\(?:" prefix space-maybe symbol: sexp space-maybe suffix-again spac= e-maybe eol-again "\\)*" prefix space-maybe "End:" space-maybe suffix space-maybe "\\(" eol-aga= in "\\)?" ) nil t) ;; when the tailing eol is not there we must be at EOB. (or (match-string 3) (eobp))) "ok" "nak")))) Vincent. --- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 26 07:39:30 2017 Received: (at 27391) by debbugs.gnu.org; 26 Jun 2017 11:39:31 +0000 Received: from localhost ([127.0.0.1]:38109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPSMc-0001zk-L4 for submit@debbugs.gnu.org; Mon, 26 Jun 2017 07:39:30 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:35487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPSMb-0001zW-Dl for 27391@debbugs.gnu.org; Mon, 26 Jun 2017 07:39:29 -0400 Received: by mail-oi0-f54.google.com with SMTP id c189so52753936oia.2 for <27391@debbugs.gnu.org>; Mon, 26 Jun 2017 04:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z86JN2rVkqfvOk6DirNmb9+8mSS1Qosu2BUQg3js4Ik=; b=kMhpaHqCIHGytfx+fD36ri7pwe2kAzH4stL2o07Od019jv7KxjZ9/h0lzJkJ565cM2 qy6cnyksEEthYWieawB5E2+juMTr2/4iC3WIRjCyQspQVtqR93MRBfMEDJBXkklsXjNT q5NC04mQZ4eACaQYmUR3DsBLirnMDNBjY5aUdHKqzkhuDbLYvj2RnskM9YHLwUh+2FrY 0+w55RS/AqwbVokcVU1jzQmx1GH7tLPks9EGyMJINMZdUewbGsYSB1g/TUBoeCua8YMb 4T97AsAU0btWEw2XAOROFXCa9OzTSJsKr70zkP7AM0tLlQorY4ub50cObbbbvWhqJsu5 RICg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z86JN2rVkqfvOk6DirNmb9+8mSS1Qosu2BUQg3js4Ik=; b=gReI+VHArELXSFRatystD2GHcNHX27oC9mVSeKSd1VhUfF8S1HmUjElnH8cRcNLcGo 44J9t1wiZ9hJe5nqwElzLdSCopr7idxDHeQIYevwN1dmUE5DS5a/jgGiKuc8wS6iljil VdA8UMadqG68D23PnbwrQy6hnsIjwhWJ2ORMsWUembyPMaRzz/gh0S8iCMoxVC1OWZRR 7AU4ResVRk2birsvpEUhWPVHhE2NMh7fWQ69dL2gniXMd/aiMWpjtx8ofRhjMDuVZ63E wYZbK/Uz1WZWwQsnJIW6usoUSTazsAfS4zUpnWhiCDs1p8/feVZfCu4d54/z/O6Gp6Yf SsPw== X-Gm-Message-State: AKS2vOyg6e5QU4FogOG4cPcJheB3agPKsf6AFN+GQouGu/h9Sr7jbN0k ZaOqZXg1FTmO0BLnIVlgro+LhzNmfA== X-Received: by 10.202.98.197 with SMTP id w188mr5085880oib.191.1498477163555; Mon, 26 Jun 2017 04:39:23 -0700 (PDT) MIME-Version: 1.0 References: <84lgooxnbe.fsf@gmail.com> In-Reply-To: <84lgooxnbe.fsf@gmail.com> From: Philipp Stephani Date: Mon, 26 Jun 2017 11:39:12 +0000 Message-ID: Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file To: =?UTF-8?Q?Vincent_Bela=C3=AFche?= , 27391@debbugs.gnu.org Content-Type: multipart/alternative; boundary="001a113d2bde09b1490552db67e6" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27391 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --001a113d2bde09b1490552db67e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Bela=C3=AFche schrieb am Mo., 19. Juni= 2017 um 12:51 Uhr: > > Concerning factorization, couldn't one use [\n\r] in all cases rather > than a switch based on some input argument ? > It should be possible, but it slightly changes the behavior of file-local variables. I wouldn't expect anything to break though. > > I was also wondering whether it is not possible to have a single regexp > for the whole Local Variable section. The following `doit' function is a > trial to do so. `M-x doit' will seach forward the whole Local Variables > section and display "ok" if found, "nak" otherwise. > > (defun doit () > (interactive) > (let* ((eol "\\(\r\n?\\|\n\\)") > (eol-again "\\1") > (space-maybe "[ \t]*") > ;; suffix may be the empty string > (suffix "\\([^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\|\\)") > (prefix "\\([ \t]*[^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\)") > (prefix-again "\\2") > (suffix-again "\\3") > (symbol: "\\(?:\\(?:[^][()'\" \t\r\n]\\|\\\\[][()'\" \t]\\)+[ > \t]*:\\)") > (sexp (concat "\\(?:" (substring prefix 2)))) > > (message (if (and (re-search-forward > (concat eol > prefix space-maybe "Local Variables:" > space-maybe suffix space-maybe eol-again > "\\(?:" prefix space-maybe symbol: sexp > space-maybe suffix-again space-maybe eol-again "\\)*" > prefix space-maybe "End:" space-maybe suffix > space-maybe "\\(" eol-again "\\)?" > ) > nil t) > ;; when the tailing eol is not there we must be at EOB. > (or (match-string 3) (eobp))) > "ok" "nak")))) > > > Looks good. Consider using `rx' for complex regexes, in my experiences it increases readability a lot. --001a113d2bde09b1490552db67e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Vincen= t Bela=C3=AFche <vincent.b= elaiche@gmail.com> schrieb am Mo., 19. Juni 2017 um 12:51=C2=A0Uhr:<= br>

Concerning factorization, couldn't one use [\n\r] in all cases rather than a switch based on some input argument ?

It should be possible, but it slightly changes the behavior of file-l= ocal variables. I wouldn't expect anything to break though.=C2=A0
=
=C2=A0

I was also wondering whether it is not possible to have a single regexp
for the whole Local Variable section. The following `doit' function is = a
trial to do so. `M-x doit' will seach forward the whole Local Variables=
section and display "ok" if found, "nak" otherwise.

(defun doit ()
=C2=A0 (interactive)
=C2=A0 (let* ((eol "\\(\r\n?\\|\n\\)")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(eol-again "\\1")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(space-maybe "[ \t]*")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; suffix may be the empty string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix=C2=A0 "\\([^ \r\n]+\\(?:[^\r= \n]*[^ \r\n]\\)?\\|\\)")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(prefix "\\([ \t]*[^ \r\n]+\\(?:[^\r= \n]*[^ \r\n]\\)?\\)")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(prefix-again "\\2")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(suffix-again "\\3")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(symbol: "\\(?:\\(?:[^][()'\&quo= t; \t\r\n]\\|\\\\[][()'\" \t]\\)+[ \t]*:\\)")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(sexp (concat "\\(?:" (substrin= g prefix 2))))

=C2=A0 =C2=A0 (message (if (and (re-search-forward
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat eol<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 prefix space-maybe "Local Variables:" space-may= be suffix space-maybe eol-again
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "\\(?:" prefix space-maybe symbol:=C2=A0 sexp s= pace-maybe suffix-again space-maybe eol-again "\\)*"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 prefix space-maybe "End:" space-maybe suffix sp= ace-maybe "\\(" eol-again "\\)?"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nil t)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; when the = tailing eol is not there we must be at EOB.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (or (match-s= tring 3) (eobp)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ok" "n= ak"))))



Looks good. Consider using `rx' fo= r complex regexes, in my experiences it increases readability a lot.=C2=A0<= /div>
--001a113d2bde09b1490552db67e6-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 27 02:05:17 2017 Received: (at 27391) by debbugs.gnu.org; 27 Jun 2017 06:05:17 +0000 Received: from localhost ([127.0.0.1]:39867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPjcj-0008VX-BA for submit@debbugs.gnu.org; Tue, 27 Jun 2017 02:05:17 -0400 Received: from smtp03.smtpout.orange.fr ([80.12.242.125]:31066 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPjch-0008VG-C3 for 27391@debbugs.gnu.org; Tue, 27 Jun 2017 02:05:15 -0400 Received: from AigleRoyal ([86.214.235.176]) by mwinf5d57 with ME id di511v00M3p1sk603i51y7; Tue, 27 Jun 2017 08:05:09 +0200 X-ME-Helo: AigleRoyal X-ME-Auth: dmluY2VudGJlbGFpY2hlQG9yYW5nZS5mcg== X-ME-Date: Tue, 27 Jun 2017 08:05:09 +0200 X-ME-IP: 86.214.235.176 From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=) To: Philipp Stephani , 27391@debbugs.gnu.org Subject: Re: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file In-Reply-To: Date: Tue, 27 Jun 2017 08:05:05 +0200 Message-ID: <8460fi7ypa.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Antivirus: Avast (VPS 170626-4, 26/06/2017), Outbound message X-Antivirus-Status: Clean X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 27391 Cc: Eli Zaretskii , =?iso-8859-1?Q?Vincent_Bela=EFche?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) My answers inserted below. Le 26/06/2017 =E0 13:39, Philipp Stephani a =E9crit : > > > Vincent Bela=EFche schrieb am Mo., 19. Juni = 2017 um 12:51 Uhr: > > > Concerning factorization, couldn't one use [\n\r] in all cases > rather than a switch based on some input argument ? > > > It should be possible, but it slightly changes the behavior of > file-local variables. I wouldn't expect anything to break though. > > Sorry, I can't understand why there should be any slight change in the current behaviour. BTW, as in the doit function given below what I had in mind was some "\\(\r\n?\\|\n\\)" construct rather than a plain "[\r\n]", so it consistently matches CR (as one some Apple computers), CR-LF (as on MSW) and LF. > > I was also wondering whether it is not possible to have a single rege= xp > for the whole Local Variable section. The following `doit' function i= s a > trial to do so. `M-x doit' will seach forward the whole Local Variabl= es > section and display "ok" if found, "nak" otherwise. > > (defun doit () > (interactive) > (let* ((eol "\\(\r\n?\\|\n\\)") > (eol-again "\\1") > (space-maybe "[ \t]*") > ;; suffix may be the empty string > (suffix "\\([^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\|\\)") > (prefix "\\([ \t]*[^ \r\n]+\\(?:[^\r\n]*[^ \r\n]\\)?\\)") > (prefix-again "\\2") > (suffix-again "\\3") > (symbol: "\\(?:\\(?:[^][()'\" \t\r\n]\\|\\\\[][()'\" \t]\\)+= [ \t]*:\\)") > (sexp (concat "\\(?:" (substring prefix 2)))) > > (message (if (and (re-search-forward > (concat eol > prefix space-maybe "Local Variables:" space= -maybe suffix space-maybe eol-again > "\\(?:" prefix space-maybe symbol: sexp sp= ace-maybe suffix-again space-maybe eol-again "\\)*" > prefix space-maybe "End:" space-maybe suffi= x space-maybe "\\(" eol-again "\\)?" > ) > nil t) > ;; when the tailing eol is not there we must be at = EOB. > (or (match-string 3) (eobp))) > "ok" "nak")))) > > > > Looks good. Consider using `rx' for complex regexes, in my experiences it= increases readability a lot. On second thought the regexp considered above has some limitation : it would fail if the sexp is multiline. For instance the following would fail. --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8---- /* Local Variables: */ /* multiline-sexp: ( "first line" "second line" ) */ /* End: */ --8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8---- This is a regression as I think that the current code allows multiline --- well I am not 100% sure of that, I presume this just from my reading the current code. I don't know if multiline sexps in file local variables is a desirable feature, personally I have never used them. And I am not even sure either that making a regexp that matches an Elisp sexp is feasible, or sensible. It is not sensible in my opinion because any change in the Elisp reader --- like supporting bignums as we had discussed quite some day ago with Jay Belanger, maintainer of Calc --- would imply some change in this regexp. And regpexps do not support either any [:elisp-sexp:] construct that would do the job with some `read' call under the hood. Vincent. --- L'absence de virus dans ce courrier =E9lectronique a =E9t=E9 v=E9rifi=E9e p= ar le logiciel antivirus Avast. https://www.avast.com/antivirus From unknown Sun Aug 17 04:19:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 25 Jul 2017 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator