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: On language-dependent defaults for character-folding Date: Sat, 13 Feb 2016 09:20:39 -0800 (PST) Message-ID: <7fbb8bc7-9a97-4bad-a103-a6690a35241d@default> References: <87mvr9wxqz.fsf@wanadoo.es> <87io1xwq1e.fsf@wanadoo.es> <87vb5wvzfz.fsf@mail.linkov.net> <87io1wt4cc.fsf@wanadoo.es> <8737syoima.fsf@mail.linkov.net> <871t8iu277.fsf@wanadoo.es> <83d1s28kvh.fsf@gnu.org> <87r3gis7sm.fsf@wanadoo.es> <83twle71xy.fsf@gnu.org> <87io1us0te.fsf@wanadoo.es> <83pow26svf.fsf@gnu.org> <87a8n5srbp.fsf@wanadoo.es> <83d1s17npz.fsf@gnu.org> <87oablfpn3.fsf@mail.linkov.net> <834mdd6llx.fsf@gnu.org> 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 1455384071 13238 80.91.229.3 (13 Feb 2016 17:21:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Feb 2016 17:21:11 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Eli Zaretskii , Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 13 18:20:58 2016 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 1aUdsP-0005NY-6X for ged-emacs-devel@m.gmane.org; Sat, 13 Feb 2016 18:20:57 +0100 Original-Received: from localhost ([::1]:43609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUdsL-0003ri-1j for ged-emacs-devel@m.gmane.org; Sat, 13 Feb 2016 12:20:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUdsH-0003rW-ED for emacs-devel@gnu.org; Sat, 13 Feb 2016 12:20:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUdsG-0005gQ-9P for emacs-devel@gnu.org; Sat, 13 Feb 2016 12:20:49 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUdsC-0005eS-DM; Sat, 13 Feb 2016 12:20:44 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1DHKg0W023236 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Feb 2016 17:20:42 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1DHKfXi001313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2016 17:20:42 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1DHKfmR009659; Sat, 13 Feb 2016 17:20:41 GMT In-Reply-To: <834mdd6llx.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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:199888 Archived-At: > The implementation should really be on the C level, like the > case-folding support. The current implementation isn't, and > therefore has several disadvantages some of which were already > pointed out (e.g., the regexp it uses that gets exposed in some > situations and causes users to be surprised). I would like to see a list of the disadvantages laid out clearly. In general, I prefer that things be implemented in Lisp. That leaves them far more open to Emacs users, and hence to imagination and enhancement - which can often help Emacs farther down the road. Implementation in C makes great sense in some cases, but it would help to see the detailed arguments (cases). The argument that a complex, not-user-friendly, under-the-covers regexp might sometimes get exposed to users is OK, but it is not really compelling (for me). Some users, in some case, might well want to make use of such a regexp (e.g. tweaking it). And we might be able to find ways to not expose it for most uses. (I don't reject the messy-regexp argument. I just don't find it sufficiently compelling on its own.) > For these and other reasons,=20 Can we see them, please? > I also think we will be unable to move to the higher levels > mentioned above without first moving the implementation into=20 > search_buffer. How so? (Reasons.) If there are important, e.g., performance reasons for coding some functionality in C, can we at least try to limit it - do that in component pieces rather than as a monolithic take-it-or-leave-it whole? I'm interested in maximizing what Lisp users can do with this, other things being equal (IOW, use C only for what is absolutely necessary).