emacs-devel
[Top][All Lists]
Advanced

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

RE: char equivalence classes in search - why not symmetric?


From: Drew Adams
Subject: RE: char equivalence classes in search - why not symmetric?
Date: Tue, 1 Sep 2015 11:46:11 -0700 (PDT)

> > > We are asking for matches that disregard the diacriticals
> > > (and in case of ª also higher-order collation-order variation).
> >
> > No.  You are asking for that only when you use a search pattern
> > that does not use the diacriticals.  When you search with á in
> > the pattern you are NOT asking for matches that disregard the
> > diacriticals.  And why not?
> 
> Because á does include a diacritical.  By specifying it, the user told
> us the diacriticals are important, and shouldn't be disregarded.

Again, you are just parroting what the implementation does, not
giving a reason supporting it.  By turning on folding, a user
can be said to be choosing to disregard diacriticals.

Again, both options for fold matching should probably be available.
There is no reason to hard-code one of them at design time.

At least no reason has been put forth so far.
 
> > > It's what the Unicode Standard recommends, and IMO it makes a
> > > lot of sense.  See http://unicode.org/reports/tr10/#Searching.
> >
> > I don't see that, when reading that section.  I do see that it
> > explicitly calls out that behavior as an _option_:
> >
> >   8.2 Asymmetric Search
> >   Users often find asymmetric searching to be a useful option.
> 
> "Users often find asymmetric searching to be a useful option" sounds
> like a recommendation to me.

No, it is not.  Not at all.  That, and all of the text about this,
makes clear, AFAICT, that this is a useful OPTIONAL behavior.

That is the language used: "a useful option".  Nowhere (AFAICT)
is there any language supporting an interpretation of this as
the recommended behavior.

The language instead clearly points out that there are different
behaviors covered by the report.  And the one that is complex and
needs explanation is clearly called out as an optional behavior.

Not the recommended behavior, but a useful behavior to consider
for inclusion as an option.

Anyway, thanks for confirming that there was not some text
that I missed, which in fact recommends asymmetric matching.



reply via email to

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