GNU bug report logs - #27391
25.2.50; utf-8 coding cookie is not applied on some specific markdown file

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Vincent Belaïche <vincent.belaiche <at> gmail.com>,  Eli Zaretskii <eliz <at> gnu.org>, 27391 <at> debbugs.gnu.org
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 part 1 (text/plain, inline)]

Vincent Belaïche <vincent.belaiche <at> gmail.com> schrieb am Sa., 17. Juni 2017
um 07:45 Uhr:

>
>
> Le 17/06/2017 à 00:23, Vincent Belaïche a écrit :
> >
> >
> * 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 = 0x0,
  file_local_flag_use_bol_eol = 0x1,
  file_local_flag_search_trailer = 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.