From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Single quotes in Info Date: Thu, 29 Jan 2015 18:03:43 +0200 Message-ID: <83vbjpmv4w.fsf@gnu.org> References: <87twzhgk84.fsf@wmi.amu.edu.pl> <83lhksshdm.fsf@gnu.org> <9ee0c895-a178-40e1-b1c8-ed2b97071c6b@default> <87h9vgglkz.fsf@wmi.amu.edu.pl> <83h9vcp0bq.fsf@gnu.org> <83y4onorcc.fsf@gnu.org> <83vbjrnd1f.fsf@gnu.org> <83386untcd.fsf@gnu.org> Reply-To: Eli Zaretskii 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 1422547456 6022 80.91.229.3 (29 Jan 2015 16:04:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 16:04:16 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 17:04:15 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 1YGrZj-00062Z-Kb for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 17:04:11 +0100 Original-Received: from localhost ([::1]:60533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGrZi-0000PJ-UU for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 11:04:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGrZZ-0000DO-1c for emacs-devel@gnu.org; Thu, 29 Jan 2015 11:04:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGrZU-00049P-Un for emacs-devel@gnu.org; Thu, 29 Jan 2015 11:04:00 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:58197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGrZU-000498-Im for emacs-devel@gnu.org; Thu, 29 Jan 2015 11:03:56 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NIY00B0042NFC00@mtaout27.012.net.il> for emacs-devel@gnu.org; Thu, 29 Jan 2015 17:57:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIY00AM84BESF10@mtaout27.012.net.il>; Thu, 29 Jan 2015 17:57:14 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:181989 Archived-At: > Date: Wed, 28 Jan 2015 22:01:09 -0800 (PST) > From: Drew Adams > Cc: emacs-devel@gnu.org >=20 > > I'm not at all sure we should compare a and =C3=A1 equal. It's a= n > > additional feature anyway. >=20 > I get the impression that you are talking only about a built-in > (more or less hard-coded, predefined) set of equivalence classes > of chars, whatever that set might be defined as. We certainly should have predefined equivalence support based on the Unicode Standard's recommendations. That is the state of the art these days, and any respectable text editor should include such support. > Is that right, or would users be able to define the equivalence > classes you are thinking of? We should first provide users with a set of sensible optional behaviors that they are likely to expect in various situations. Each option will invoke a certain predefined behavior, such as whether or not equivalence classes are at all considered, whether or not a and = =C3=A1 compare equal, etc. There are important use cases for each one of those, exactly like there important use cases for both case-sensitive and case-insensitive search. Once we have that in place, we can add user-defined additions. I expect them to be relatively minor and mostly mode-specific, such as the special treatment of quotes and other special characters in Info buffers. Why minor? because Unicode already thought out and defined almost any imaginable feature in this regard, so chances that some user might need something in addition are small. Mode-specific additions could be just alists that map characters or strings to their equivalents. Since I don't expect those to become large, there's no need for anything fancier, IMO. > If they would not then a separate but desirable (IMO) feature > would be for users to be able to easily define their own such > equivalence classes. I wouldn't call them equivalence classes. Users are not expected to be experts in Unicode features, its various data tables, and their implementation in Emacs. We should instead provide easy-to-customize option variables to select out of an array of predefined features based on Unicode tables we already have. User additions should be some simple data structure that don't require any special expertise.