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: ASCII-folded search [was: Re: Upcoming loss of usability ...] Date: Fri, 26 Jun 2015 15:54:58 -0700 (PDT) Message-ID: References: <20150615142237.GA3517@acm.fritz.box> <87ioamz8if.fsf@petton.fr> <32013464-2300-46c6-ba46-4a3c36bfee5d@default> <87twu62nnt.fsf@mbork.pl> <87oakdfwim.fsf@uwakimon.sk.tsukuba.ac.jp> <83wpz1lh7c.fsf@gnu.org> <83oakdl7yj.fsf@gnu.org> <83ioall3x5.fsf@gnu.org> <87h9pzxtyi.fsf@mail.linkov.net> <87k2uudoqr.fsf@mail.linkov.net> <87616c94g4.fsf@mail.linkov.net> <87h9pw6922.fsf@mail.linkov.net> <87a8vn75r7.fsf@mail.linkov.net> <0f72b0bd-0170-414c-b926-0b836a973d67@default> <9b42a5bc-48e3-4111-b37d-280867903527@default> <12de813f-cffa-4231-95a4-5b9ee2709123@default> 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 1435359340 9256 80.91.229.3 (26 Jun 2015 22:55:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 22:55:40 +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 Sat Jun 27 00:55:27 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 1Z8cWs-0003eG-Bg for ged-emacs-devel@m.gmane.org; Sat, 27 Jun 2015 00:55:26 +0200 Original-Received: from localhost ([::1]:33977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cWo-0001PU-IB for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 18:55:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cWY-0001Mo-OX for emacs-devel@gnu.org; Fri, 26 Jun 2015 18:55:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8cWT-00051D-O8 for emacs-devel@gnu.org; Fri, 26 Jun 2015 18:55:06 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:39354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cWT-0004zV-IF for emacs-devel@gnu.org; Fri, 26 Jun 2015 18:55:01 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5QMsxTA018766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Jun 2015 22:54:59 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t5QMsx13015853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Jun 2015 22:54:59 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5QMsxMF016577; Fri, 26 Jun 2015 22:54:59 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: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:187584 Archived-At: > Just to be clear, when I talk about the possibility of this being > futurely implemented, I'm referring to the "independent" part, not > the "multiple" part. > > I agree multiple char folding is where this should go, Great. Then lets assume that and discuss the UI framework that should handle it. > I just don't agree it is important for these multiple options > to be visually distinguishable (or independently toggleable) > during isearch. Then you should feel the same about indicating case folding. I don't. And you should feel the same about distinguishing case folding from what your implementation of char folding provides. In that case, you should want only one indicator, which shows that search is currently folding *something*, and let users guess what that something might be. I think that, *especially* when there are multiple possible char foldings, seeing which ones are currently in effect is important/useful. > May be you can convince me otherwise. But I think that most > users will never customize the equivalence class used. Most users never toggle case sensitivity, perhaps. So what? I still think it is a good idea to visually indicate (e.g., in the lighter) whether search is currently case-sensitive. Anyway, it's not only or especially about user creation of custom equivalence classes. (But yes, I think that that too is important.) I'm hoping for some predefined sets of common equivalences. Things like diacritical marks, numerals of different kinds, smallcaps/caps, smallcaps/lowercase, circled/uncircled, parenthesized/unparenthesized, arrows & brackets & pointers & such, quotes & guillmets, fullwidth-latin/latin, non-ascii, math-symbol groups... And classes that might make sense for different languages, just as case insensitivity is useful for latin languages. Who knows? I can guess that there will be at least *two* besides the current one (case-insensitivity). And given that possibility, users will want to distinguish them easily. I'm pretty sure of that. Just as I'm guessing that you probably do want to distinguish case folding from your new char folding, with a visual indication for each. > From those that do customize it, most will never toggle it > during interactive searches. Why do you think that? Will you never toggle abstracting from accents/diacriticals? Do you never toggle case sensitivity? Why would a user-defined equivalence class be any different in this regard? > From those that do toggle it, most of them will prefer an > "all-or-nothing" toggle/indicator. Why? By that logic, you would prefer only one now, for both case sensitivity and your new (other) char folding. Don't you want to see *both* whether search is case sensitive and whether it is abstracting from diacriticals or whatever? Why not? > And then there are the few of the few of the few There are a lot of users out there, and more and more of them use Unicode chars that you and I might never use. Starting with languages that you and I might never search. > who wish they could see which equiv-classes are on or off, > or wish they could toggle them independently during isearch. > Which is great! But we shouldn't come up with a complex > interface to satisfy this need if it's just gonna > confuse a lot of other people. We should come up with a flexible UI that is as simple as possible while supporting the assumption of more than two char foldings (with your addition we will already have two). We don't need to predefine toggle commands for things that are not there now. No one is suggesting that we do that. But we should make it easy for users to adapt what we do provide for use with other character-equivalence classes - both to add toggle commands and to add/modify a visual indicator for their needs. We should set the pattern now, based on assuming not just two equivalence classes (including case sensitivity), but 3 or more.