From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `char-fold-table' Date: Wed, 2 Sep 2015 09:05:12 -0700 (PDT) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441209965 23256 80.91.229.3 (2 Sep 2015 16:06:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 16:06:05 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 02 18:05:51 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZXAXl-0002uF-KX for ged-emacs-devel@m.gmane.org; Wed, 02 Sep 2015 18:05:49 +0200 Original-Received: from localhost ([::1]:39220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXAXl-0005zX-Gs for ged-emacs-devel@m.gmane.org; Wed, 02 Sep 2015 12:05:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXAXO-0005ZC-2k for emacs-devel@gnu.org; Wed, 02 Sep 2015 12:05:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXAXI-0004i6-FE for emacs-devel@gnu.org; Wed, 02 Sep 2015 12:05:26 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:50603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXAXI-0004hu-9G for emacs-devel@gnu.org; Wed, 02 Sep 2015 12:05:20 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t82G5ELv030445 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2015 16:05:14 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t82G5ElL030189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2015 16:05:14 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t82G5DL9003142; Wed, 2 Sep 2015 16:05:14 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189474 Archived-At: > > 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? >=20 > 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? >=20 > 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. >=20 > 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.