From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: ASCII-folded search [was: Re: Upcoming loss of usability ...] Date: Sat, 27 Jun 2015 09:07:56 +0100 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> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2354cac20f605197b5aa3 X-Trace: ger.gmane.org 1435392505 5291 80.91.229.3 (27 Jun 2015 08:08:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jun 2015 08:08:25 +0000 (UTC) Cc: emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 27 10:08:13 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 1Z8l9n-0004Bn-VB for ged-emacs-devel@m.gmane.org; Sat, 27 Jun 2015 10:08:12 +0200 Original-Received: from localhost ([::1]:34786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8l9n-0002tj-9k for ged-emacs-devel@m.gmane.org; Sat, 27 Jun 2015 04:08:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8l9b-0002te-4u for emacs-devel@gnu.org; Sat, 27 Jun 2015 04:08:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8l9Z-0004xN-Hi for emacs-devel@gnu.org; Sat, 27 Jun 2015 04:07:59 -0400 Original-Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:32920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8l9Z-0004wz-5E for emacs-devel@gnu.org; Sat, 27 Jun 2015 04:07:57 -0400 Original-Received: by laar3 with SMTP id r3so16358732laa.0 for ; Sat, 27 Jun 2015 01:07:56 -0700 (PDT) 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=4VSOFfxc4RFtX9lHXbLK6YpwZ6cppfsn+z/3i0njCxM=; b=dF4ajhY5GyqI9uefq/3vovjqslwPJDq3XDJXJswZv1vXAusQMW6fE0+1EIntbXa7tA MWdSoUcncdOfy2spLJnh9ZR7XUZbWJVAML+Cahzaf2cbBwR5nLqcMRv7LWku4rOXlY/q Zmb+DTDTkoTjmDLsfi1Gsq6ofG7GC9HfXD7n57lnAqpLAHCQbHuvlw/kcGGFKIl+Uf9t 4OvqQkoLS6mogh761EsNQ93sGAZp0Jmogz3ab9A9NXG47ZZiuXMCvBWnwENHr3dsX0uh Z5S3jxsHSz+0AebKDsGs8Qge4y4AnUh98fRWU8cxks5aSHY0bBJkLEqi2hSphum0UZCv QS/g== X-Received: by 10.152.87.231 with SMTP id bb7mr5075566lab.16.1435392476453; Sat, 27 Jun 2015 01:07:56 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Sat, 27 Jun 2015 01:07:56 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Sat, 27 Jun 2015 01:07:56 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: h6drItbuO5lAqIwMKtjdHfZes_4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::231 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:187587 Archived-At: --001a11c2354cac20f605197b5aa3 Content-Type: text/plain; charset=UTF-8 >> 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. > >> 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. We can afford to distinguish 2 or 3 different types of char-folding, We just can't afford to (and have little reason to) make an arbitrary number of arbitrary equiv classes distinguishable during search. case folding is significant enough to warrant being one of these 2 or 3 (not to mention it's trivial to do internally). If there's another equivalence class that we think outshines the rest we can distinguish it too. > I think that, *especially* when there are multiple possible > char foldings, seeing which ones are currently in effect is > important/useful. I disagree, because I think the vast majority of people will always use the same set foldings. For this majority, it's better to only show whether it's ON or OFF, because that's simpler to read and to discern the meaning. >> 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. Indeed. "The few" I'm referring to is not "users who use unicode", it's "users who customize charfolding, and toggle it mid-isearch, and want to toggle specific equiv classes mid-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). No, we *can* try come up with a utopic UI, that doesn't mean we should. And it does't mean we should deny willing patches while we throw essays around to come up with that UI. Specially when it's a simple thing that's trivial to revert with git. --001a11c2354cac20f605197b5aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>> From those that do toggle it, most of them will pre= fer 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.
>
>> I just don't agree it is important for these multiple options<= br> >> to be visually distinguishable (or independently toggleable)
>> during isearch.
>
> Then you should feel the same about indicating case folding.

I don't. We can afford to distinguish 2 or 3 different t= ypes of char-folding, We just can't afford to (and have little reason t= o) make an arbitrary number of arbitrary equiv classes distinguishable duri= ng search.

case folding is significant enough to warrant being one of t= hese 2 or 3 (not to mention it's trivial to do internally). If there= 9;s another equivalence class that we think outshines the rest we can disti= nguish it too.

> I think that, *especially* when there are multiple poss= ible
> char foldings, seeing which ones are currently in effect is
> important/useful.

I disagree, because I think the vast majority of people will= always use the same set foldings. For this majority, it's better to on= ly show whether it's ON or OFF, because that's simpler to read and = to discern the meaning.

>> 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.

Indeed. "The few" I'm referring to is not &quo= t;users who use unicode", it's "users who customize charfoldi= ng, and toggle it mid-isearch, and want to toggle specific equiv classes mi= d-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).

No, we *can* try come up with a utopic UI, that doesn't = mean we should. And it does't mean we should deny willing patches while= we throw essays around to come up with that UI. Specially when it's a = simple thing that's trivial to revert with git.

--001a11c2354cac20f605197b5aa3--