emacs-devel
[Top][All Lists]
Advanced

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

Re: Single quotes in Info


From: Eli Zaretskii
Subject: Re: Single quotes in Info
Date: Tue, 27 Jan 2015 20:04:09 +0200

> Date: Tue, 27 Jan 2015 14:27:45 -0200
> From: Artur Malabarba <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, help-gnu-emacs <address@hidden>
> 
> I also really like this idea, so much so that I've gone ahead and
> implemented it. It is implemented on the branch
> `scratch/isearch-character-group-folding'. I called it group-folding,
> but we can call it class folding or whatever sounds more intuitive to
> most people.

I didn't yet have time to look at the source, so apologies if what's
below is off the mark.

> The implementation is very much up for debate. Currently, what it does
> is use regexps (behind the scenes) so that a plain double quote
> matches all those unicode double quotes, and the same for a hard
> single quote. The way it is written, it is trivial to add more groups
> by adding entries to `isearch-groups-alist'.
> Of course, other characters are appropriately regexp-quoted behind the
> scenes, so that everything else works as expected. The surface is
> exactly like regular isearch, except for these two characters.

If this is implemented in isearch, then IMO doing it for quotes alone
makes very little sense.  It would make a lot of sense if it were
implemented in info.el, for searching Info manuals (in which case it
should also support the other Unicode characters produced by makeinfo
that have ASCII equivalents, like ⇒ vs =>.  (Note that this is not
character-for-character equivalence anymore.)

For a general-purpose search feature, we'd need a much more
general-purpose and versatile implementation.

> The set of groups is defined by `isearch-groups-alist', and the
> folding only happens if `isearch-fold-groups' is non-nil.
> Other groups that maybe should be added are latin accented letters.

If we do this via our private database, that database is going to be
huge.  I suggest to explore an alternative implementation, which uses
canonical equivalence.  We already have infrastructure for that, see
the description of the 'decomposition' character property in the ELisp
manual.




reply via email to

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