bug#13084: boyer_moore crashes with certain characters in the case table

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: handa@gnu.org,  13084@debbugs.gnu.org
> Date: Wed, 12 Dec 2012 11:27:50 +0200
> 
> >> Does this mean there are no more obstacles to filling a translation table
> >> for ignoring equivalence with all character mappings according to the
> >> `decomposition' property?  This would be the first step in this direction.
> >
> > I'm not sure I understand what you are asking.  Please show more details.
> 
> There is confusion with the word `equivalence'.  Currently there
> exists the case equivalence table in the case table (`case_eqv_table').
> Implementing a diacritic search in bug#13041 requires adding a new
> similar table.  I don't know what would be a good name:
> `decomposition_eqv_table' or `normalization_eqv_table' or something better.
> 
> I'm unfamiliar with the details of `search_buffer', but in principle
> using two tables in the macro `TRANSLATE' could implement a diacritic
> search where at the first step the character will be translated using
> `decomposition_eqv_table', and after that the resulting character
> will be translated using `case_eqv_table'.
> 
> So the dataflow to get the canonical character will be Á -> A -> a.
> If `case-fold-search' is nil, then Á -> A.  If a new variable
> `decomposition-search' (or `normalized-search') is nil then Á -> á.

OK, all this is now clear and agreed.  So what did you mean by "no
more obstacles" above?  The obstacles I see is that case tables aren't
up to the job because they don't support ignoring of characters, and
the code in search.c cannot handle ignoring even if the table did
support that.  These obstacles still stand.