`char-fold-table'

`char-fold-table'

[Drew Adams]

Why is `char-fold-table' a defconst?

When this feature was introduced, while applauding it I
pointed to the aim of letting users and libraries define
their own equivalence classes of chars, for character
folding.

I was told to hold off, that while that is a goal, we
should not discuss it now because that might interfere
with accomplishing a preliminary version of char folding.
And that users could always modify the char table provided
or create their own, to modify the behavior.

OK.

So here we are now, with char folding.  Great.  So can
we now consider facilitating users defining their own
classes of characters?  Or making it easy for them to
modify the default equivalence classes?

Making `char-fold-table' a defconst seems wrong.  What's
the right way to enable users and code to customize such
things?

Not only do we hard-code the equivalence classes, but we
don't even tell users what they are.  Not really.  The
only thing they have so far is option - nay, defvar,
`character-fold-search', whose doc tells them only that

 "some characters will match entire groups of characters.
  For instance, " will match all variants of double quotes
  and the letter a will match all of its accented versions
  (and then some)"

"some characters"?  "For instance"?  "(and then some)"?

Yes, I know that the doc for this feature is still to be 
written, and that this the feature is still a work in
progress.  But let's please progress it - in the direction
of more and better info for users and helping users modify
and extend the behavior.

Re: `char-fold-table'

[Artur Malabarba]

> So here we are now, with char folding.  Great.  So can
> we now consider facilitating users defining their own
> classes of characters?  Or making it easy for them to
> modify the default equivalence classes?

My thoughts are still focused on ironing out some issues. But this is
a fine time to start suggesting ways to make it customizable.

> Making `char-fold-table' a defconst seems wrong.  What's
> the right way to enable users and code to customize such
> things?

In the very least we can rename the current table to
character-fold-table-default, and make let the user change
character-fold-table if desired.
We can also offer more alternatives besides the current default, but
it would be better to give users a good way to define classes.

> Yes, I know that the doc for this feature is still to be
> written, and that this the feature is still a work in
> progress.  But let's please progress it - in the direction
> of more and better info for users and helping users modify
> and extend the behavior.

This, along with ironing out the kinks, is my priority for this
feature. However, I'm writting my thesis right now so I won't be able
to do this for another couple of months.
Of course, if anyone would like to contribute documentation that would
be highly appreciated.

RE: `char-fold-table'

[Drew Adams]

> > So here we are now, with char folding.  Great.  So can
> > we now consider facilitating users defining their own
> > classes of characters?  Or making it easy for them to
> > modify the default equivalence classes?
> 
> My thoughts are still focused on ironing out some issues. But this
> is a fine time to start suggesting ways to make it customizable.

Agreed.  I hope folks will participate and think creatively
about this.

> > Making `char-fold-table' a defconst seems wrong.  What's
> > the right way to enable users and code to customize such
> > things?
> 
> In the very least we can rename the current table to
> character-fold-table-default, and make let the user change
> character-fold-table if desired.
> We can also offer more alternatives besides the current default, but
> it would be better to give users a good way to define classes.

Yes.  That first change could be done now, hopefully.

I'm not sure we need to come up with more alternative tables.
A simple example in the manual of how to do that yourself would,
I think, be sufficient (and necessary).  With time, perhaps some
additional "standard" tables would come into being, but I don't
see the need for trying to come up with such things now (and
maybe never).

> > Yes, I know that the doc for this feature is still to be
> > written, and that this the feature is still a work in
> > progress.  But let's please progress it - in the direction
> > of more and better info for users and helping users modify
> > and extend the behavior.
> 
> This, along with ironing out the kinks, is my priority for this
> feature. However, I'm writting my thesis right now so I won't be able
> to do this for another couple of months.
> Of course, if anyone would like to contribute documentation that would
> be highly appreciated.

Understood.  I will try to look over whatever doc is proposed -
hope that helps.  And thanks for this feature - (1) it's very
useful, and (2) more importantly, it has great potential.