From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: char equivalence classes in search - why not symmetric? Date: Mon, 07 Sep 2015 14:52:52 +0100 Message-ID: <87k2s25oaz.fsf@esperi.org.uk> References: <2a7b9134-af2a-462d-af6c-d02bad60bbe8@default> <834mjecdy7.fsf@gnu.org> <834mjcbydi.fsf@gnu.org> <83vbbs9qd1.fsf@gnu.org> <66ae6614-75bf-4b1b-9c16-5e7755a824f8@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441634002 21243 80.91.229.3 (7 Sep 2015 13:53:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Sep 2015 13:53:22 +0000 (UTC) Cc: Jean-Christophe Helary , bruce.connor.am@gmail.com, emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 07 15:53:14 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 1ZYwr8-0001ZY-ON for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 15:53:10 +0200 Original-Received: from localhost ([::1]:56775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYwr9-0004fG-7T for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 09:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYwr4-0004ch-JF for emacs-devel@gnu.org; Mon, 07 Sep 2015 09:53:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYwr1-0001VV-CS for emacs-devel@gnu.org; Mon, 07 Sep 2015 09:53:06 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:40793 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYwr1-0001Td-1r for emacs-devel@gnu.org; Mon, 07 Sep 2015 09:53:03 -0400 Original-Received: from spindle (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.15.2/8.15.2) with ESMTP id t87DqqeP004002; Mon, 7 Sep 2015 14:52:52 +0100 Emacs: a Lisp interpreter masquerading as ... a Lisp interpreter! In-Reply-To: <66ae6614-75bf-4b1b-9c16-5e7755a824f8@default> (Drew Adams's message of "Thu, 3 Sep 2015 10:15:01 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DCC-wuwien-Metrics: spindle 1290; Body=4 Fuz1=4 Fuz2=4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 81.187.191.129 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:189667 Archived-At: On 3 Sep 2015, Drew Adams spake thusly: > IMO and FWIW, it is misguided to provide confusing, dwim behavior > by default. Hard for a newbie to guess what the behavior really > is, because it is too complex, conditional, contextual, whatever. FWIW I just introduced Emacs to a newbie last month -- using trunk Emacs because that's what I happened to have available. She was very happy indeed about not only isearch, not only case-fold search but specifically char-fold search, and she writes stuff using diacritics all the time. The key to remember here is that there are many use cases in which it is better if isearch finds something similar to what you typed than if it misses something you were looking for: you can always hit C-s again! So thanks to case-fold and char-fold search she doesn't have to worry about getting either the case or diacritics right, and can cut down on chording and compose characters while searching. So that's one newbie in particular who would vociferously disagree with you. > What should be done is to have simple, obvious default behavior, She found "searching ignores accent-like things and case" to be easy and instantly understandable, even though the implementation of ignoring even case is (thanks to case-conversion tables) quite complicated in a Unicode world. -- NULL && (void)