emacs-devel
[Top][All Lists]
Advanced

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

RE: On language-dependent defaults for character-folding


From: Drew Adams
Subject: RE: On language-dependent defaults for character-folding
Date: Tue, 23 Feb 2016 10:00:29 -0800 (PST)

>   > > Some plausible meanings are
>   > >
>   > > * Find that one and only that one.
>   > > * Treat it the same as specifying the base letter.
>   > >
>   > > There should be a user option to choose between those two (and maybe
>   > > some other behaviors for a non-base letter in the search string).
>   >
>   > We already have both options, and in particular, if a non-base letter
>   > appears explicitly in the search string, it will be searched
>   > literally, similarly to what we do with case-insensitive search.
> 
> Some users want that.  Some, it appears, want searching for any letter
> in the group to find any letter in the group.  So I am suggesting we
> offer both behaviors.

+1.

That is what I did, BTW, in my add-on to character-fold.el
(option `char-fold-symmetric').

And the same user can want one or the other behavior at different
times or in different contexts.

Besides choosing a behavior as a general preference at customize
time, you can toggle the behavior during Isearch, using `M-s ='
(command `isearchp-toggle-symmetric-char-fold'):

  Toggle option `char-fold-symmetric'.
  This does not also toggle character folding.

  Note that symmetric character folding can slow down search.
  Use longer search strings to reduce this problem, or use `M-s h L'
  to turn off lazy highlighting.

Moving some of the character-fold.el implementation to C would
no doubt speed things up.  But I hope that that will be done in a
fine-grained modular way, providing individual Lisp functions that
users can tweak.

For example, I might not have been able to add this alternative
behavior easily, were it not for the current regexp-using code
in character-fold.el.  I don't expect the same Lisp functions to
be available after the implementation of some things in C, but
let's try to make sure that a C implementation is not monolithic,
preventing easy extension using Lisp.

(No, I'm not suggesting that that has been the case in the past.
Just mentioning the need to be able to extend and experiment in
Lisp.)



reply via email to

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