bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35802: Broken data loaded from uni-decomposition


From: Juri Linkov
Subject: bug#35802: Broken data loaded from uni-decomposition
Date: Thu, 06 Jun 2019 23:41:35 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> But should return `t'.  I customized `search-whitespace-regexp'
>> (whose value isearch sets to `search-spaces-regexp') to a legitimate
>> value, but `unicode-property-table-internal' used in char-fold.el fails
>> to correctly load "uni-decomposition.el", thus breaking the char-fold search.
>
> The problem is that this messes up a search in find-auto-coding:

Thanks for finding this.

>       (if (re-search-forward
>            "[\r\n]\\([^\r\n]*\\)[ \t]*Local Variables:[ 
> \t]*\\([^\r\n]*\\)[\r\n]"
>            tail-end t)
>           ...
>           (let* ((prefix (regexp-quote (match-string 1)))
>                  (suffix (regexp-quote (match-string 2)))
>
> The space between "Local Variables" becomes "\\(\\s-\\|\n\\)+" which is
> a problem because it adds a new capturing group, which means suffix gets
> the wrong value.  Then we fail to find the ";; End:" line, and don't
> apply the "coding: utf-8" setting.

When this feature is used in Isearch, the documented way to avoid this problem
is to replace the space with ‘[ ]’, i.e. to use

  "Local[ ]Variables:"

> So the value you chose isn't entirely legitimate, you should use a shy
> group instead:
>
> (equal (progn (load "international/uni-decomposition.el" t t t t)
>               (aref (cdr (assq 'decomposition char-code-property-alist)) 
> 1024))
>        (progn (let ((search-spaces-regexp "\\(?:\\s-\\|\n\\)+"))
>                 (load "international/uni-decomposition.el" t t t t))
>               (aref (cdr (assq 'decomposition char-code-property-alist)) 
> 1024)))
> ;=> t

Maybe this gotcha should be mentioned in the documentation of
search-spaces-regexp and search-whitespace-regexp?

> And possibly let-binding search-spaces-regexp in find-auto-coding would
> make sense (although, there's probably more places like this that might
> break, not sure if we can ever hope to find them all).

This is almost the same class of problems as wrapping re-search-forward
in save-match-data, so finding all places that affect matching elsewhere
will take time.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]