From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#22147: Obsolete search-forward-lax-whitespace Date: Thu, 17 Dec 2015 18:47:37 +0000 Message-ID: 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> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1450378101 28223 80.91.229.3 (17 Dec 2015 18:48:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2015 18:48:21 +0000 (UTC) Cc: 22147@debbugs.gnu.org, Juri Linkov To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 17 19:48: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 1a9db0-0004OW-5X for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Dec 2015 19:48:10 +0100 Original-Received: from localhost ([::1]:56266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9daz-00063w-Dz for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Dec 2015 13:48:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9daw-00063p-7C for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 13:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9das-0006WJ-Sj for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 13:48:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9das-0006WF-P8 for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 13:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a9das-0006Sq-Fg for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2015 13:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Dec 2015 18:48: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.145037806524826 (code B ref 22147); Thu, 17 Dec 2015 18:48:02 +0000 Original-Received: (at 22147) by debbugs.gnu.org; 17 Dec 2015 18:47:45 +0000 Original-Received: from localhost ([127.0.0.1]:54683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9daa-0006SM-T3 for submit@debbugs.gnu.org; Thu, 17 Dec 2015 13:47:45 -0500 Original-Received: from mail-lf0-f45.google.com ([209.85.215.45]:33426) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9daZ-0006S8-8y for 22147@debbugs.gnu.org; Thu, 17 Dec 2015 13:47:43 -0500 Original-Received: by mail-lf0-f45.google.com with SMTP id p203so58634380lfa.0 for <22147@debbugs.gnu.org>; Thu, 17 Dec 2015 10:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xxFp0I/S7K+xaieq3IjUDtcquF4PD9GAj0Ai/7ooVpc=; b=MMGFsUBP8/ZgaRRe73ymvzYOMYMS82aWYk4fzvp1N9xOCQz48EqY0BbxSPc9VIGYqi fJomAriX1yVMei6XR6qsrXTUnvwo5aZzzQY4Bs7IFXXrYJyOhoE/Jh+u0Bn2rHHutOGF DKFcK8mEA05CkuOET6fyG9eejVWYMrrELjeJth1UUJT+f17+euvu9ow5WYgxLcuC52i4 Boli0fXrJvWcWH8SxVLlYlta4TX1M9mxDZLvasRJLpdCqedUsd9SwwJ5BDE88VtIWRmi VQ7AEDftIxLRkN/4tC9vwtuy1aH+0rFVz4kHh7W3BWSY06ff+ApTjbdSg0hhyQ9l8FON Satw== X-Received: by 10.25.18.231 with SMTP id 100mr12865136lfs.25.1450378057359; Thu, 17 Dec 2015 10:47:37 -0800 (PST) Original-Received: by 10.112.202.99 with HTTP; Thu, 17 Dec 2015 10:47:37 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 9QD0z0kMM4ypPMtrBHk4zf4Ucvk 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:110090 Archived-At: 2015-12-17 17:21 GMT+00:00 Drew Adams : >>> char-fold-symmetric could wait for later, but we definitely need >>> char-fold-ad-hoc now before the release because the users should be >>> able to customize the default rules. >> >> Indeed. Once we do that, we also need a variable to determine >> whether we should derive the default table from the unicode >> standard (like we currently do) or just use an empty default with >> the ad-hoc rules slapped on top. > > 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, but IMO this would be over-engineering. 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, without requiring a big initial investment. Then we also make character-fold-table into a defvar, and document it as a proper exposed API, so advanced users can change it however they want with hooks and local vars to however many different values/equiv-classes they want. 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.