From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#22147: Obsolete search-forward-lax-whitespace Date: Thu, 17 Dec 2015 14:16:26 -0800 (PST) Message-ID: <9ec649c4-5d95-4192-8a73-cc438ad0e4aa@default> References: <87wpsk7dcs.fsf@mail.linkov.net> <87d1ubz3w9.fsf@mail.linkov.net> <87r3ipoofk.fsf@mail.linkov.net> <87zixcblno.fsf@mail.linkov.net> <874mfjchp1.fsf@mail.linkov.net> <87mvt9evf9.fsf@mail.linkov.net> 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 1450390644 8148 80.91.229.3 (17 Dec 2015 22:17:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2015 22:17:24 +0000 (UTC) Cc: 22147@debbugs.gnu.org, Juri Linkov To: bruce.connor.am@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 17 23:17:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1a9grG-0000HE-KF for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Dec 2015 23:17:10 +0100 Original-Received: from localhost ([::1]:57435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9grG-0003lH-2n for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Dec 2015 17:17:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9grC-0003ks-79 for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 17:17:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9gr9-0006sx-0g for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 17:17:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9gr8-0006st-Sq for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 17:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a9gr8-0002qz-5i for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 17:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Dec 2015 22:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22147 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22147-submit@debbugs.gnu.org id=B22147.145039059610931 (code B ref 22147); Thu, 17 Dec 2015 22:17:02 +0000 Original-Received: (at 22147) by debbugs.gnu.org; 17 Dec 2015 22:16:36 +0000 Original-Received: from localhost ([127.0.0.1]:54819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9gqh-0002qF-Li for submit@debbugs.gnu.org; Thu, 17 Dec 2015 17:16:35 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:47043) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9gqg-0002q3-P1 for 22147@debbugs.gnu.org; Thu, 17 Dec 2015 17:16:35 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBHMGShi014233 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Dec 2015 22:16:28 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tBHMGSwC007461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2015 22:16:28 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBHMGRdW029614; Thu, 17 Dec 2015 22:16:28 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: userv0021.oracle.com [156.151.31.71] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110095 Archived-At: > > 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. >=20 > 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. =20 > 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.