bug#22147: Obsolete search-forward-lax-whitespace

[Drew Adams <drew.adams@oracle.com>]

> > Users should be able to define their own equivalence classes (groups),
> > not just one class.  Each class should be the value of a user option.
> >
> > Here is one simple and flexible way to do this:
> >
> > 1. Define a user option, `char-folding-classes', which is a list of
> >    any number of (OPTION-NAME DOC-STRING) pairs, where OPTION-NAME
> >    is a symbol that will name a user option and DOC-STRING is its doc
> >    string.
> >
> >    Each symbol would automatically be used to define an option (a
> >    defcustom) that the user can then use to define a given equivalence
> >    class.
> >
> > 2. The generated defcustom for each user option specified in option
> >    `char-folding-classes' would allow for any number of entries, each
> >    of which could be a `choice' of either of these defcustom types:
> >
> >    a. An alist, such as used currently in my `char-fold-ad-hoc' option:
> >       Each entry is a list of a char and the strings that fold into it.
> >
> >    b. A function that populates such an alist.
> 
> I appreciate you probably put quite a bit of thought into this,

Only a few minutes of thought, as I imagine you can guess.  It just
extends what I already have in character-fold.el.

> but IMO this would be over-engineering.

How so?  I've done zero "engineering" on it.  And I don't really care
how it gets done, as long as it does.

My point, as I said, is only this:

  Users should be able to define their own equivalence classes (groups),
  not just one class.  Each class should be the value of a user option.

Anything less than that is not serving users as well as they deserve, IMO.

As to how that is done, I really don't care.  I offered one simple approach,
but you are welcome to over-, under- or just-right-engineer it your own way.

> I think we should define two simpole defcustoms that determine how the
> character-fold-table is generated: character-fold-ad-hoc (an alist)
> and character-fold-derive-from-unicode-decomposition (a boolean).
> This should be immediately configurable by anyone,

That's far too restrictive, IMO.  It does not let users or libraries
easily apply different equivalence classes for different uses (e.g.
modes).  And there is no reason for such restriction - nothing is
gained by it.

> without requiring a big initial investment.

There is no "big initial investment" to what I described.  I can code
it up quickly, as I'm sure you can too.

And what it provides out of the box is exactly the same.  It is just as
"immediately configurable by anyone" - and immediately configurable in
exactly the same way.  Your Boolean with a default value of t is
equivalent to the default presence of the function that does what your
Boolean t does: "derive-from-unicode-decomposition".

You can do more with what I described, and more easily.  But you can
also do just as little with it.
 
> Then we also make character-fold-table into a defvar, and document it
> as a proper exposed API, so advanced users

Anything that can be a defvar, for "advanced users", can be a defcustom,
for all users.

If you are inviting users to fiddle with a char-fold table, it is far
better to give them the ability to do so in a modular way, and to make
your default derive-from-unicode-decomposition into a default function
instead of just hard-coding the behavior.  Nothing lost, modularity
and flexibility gained.

> can change it however they want with hooks and local vars to however
> many different values/equiv-classes they want.

Ugly, and complicated.  And unnecessary.  No need to be an "advanced
user" and fiddle with such stuff.

> This would offer a dead-simple defcustom that covers most cases, while
> still allowing the versatility of having multiple options for those
> who need it.

What I proposed is just as "dead-simple", but cleaner (IMO) and open
to all users.  Just as importantly, it lets users (easily) define
multiple classes that they can (easily) use in different contexts.

Again, I don't care about the implementation, but I would like users
to be able to define their own equivalence classes (groups), and to
enable/disable them easily au choix.