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.