From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27391: 25.2.50; utf-8 coding cookie is not applied on some specific markdown file Date: Sat, 17 Jun 2017 14:30:49 +0000 Message-ID: References: <84wp8bxj40.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d1cf426b494055228c0f6" X-Trace: blaine.gmane.org 1497709941 8532 195.159.176.226 (17 Jun 2017 14:32:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Jun 2017 14:32:21 +0000 (UTC) To: Vincent =?UTF-8?Q?Bela=C3=AFche?= , Eli Zaretskii , 27391@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 17 16:32:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMElq-0001cY-Du for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Jun 2017 16:32:14 +0200 Original-Received: from localhost ([::1]:34972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMElq-0001xW-DL for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Jun 2017 10:32:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMElj-0001xO-W1 for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMEle-00011G-V6 for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:32:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50819) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dMEle-000112-Rt for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dMEle-0004Ly-Ij for bug-gnu-emacs@gnu.org; Sat, 17 Jun 2017 10:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Jun 2017 14:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27391 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27391-submit@debbugs.gnu.org id=B27391.149770986816674 (code B ref 27391); Sat, 17 Jun 2017 14:32:02 +0000 Original-Received: (at 27391) by debbugs.gnu.org; 17 Jun 2017 14:31:08 +0000 Original-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 Original-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 Original-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) In-Reply-To: <84wp8bxj40.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133702 Archived-At: --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--