From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.devel Subject: Re: Embedded modifiers in the regex engine Date: Thu, 25 Feb 2016 23:19:32 -0800 Message-ID: References: <87ziupinhq.fsf@secretsauce.net> <83oab4g407.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1456471674 7055 80.91.229.3 (26 Feb 2016 07:27:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 07:27:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 26 08:27:44 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 1aZCoQ-0000aC-Ia for ged-emacs-devel@m.gmane.org; Fri, 26 Feb 2016 08:27:42 +0100 Original-Received: from localhost ([::1]:47859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZCoP-0001B0-Su for ged-emacs-devel@m.gmane.org; Fri, 26 Feb 2016 02:27:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZCoK-0001Ao-U4 for emacs-devel@gnu.org; Fri, 26 Feb 2016 02:27:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZCoH-0006Ly-Lk for emacs-devel@gnu.org; Fri, 26 Feb 2016 02:27:36 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:47588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZCoH-0006Lp-Gq for emacs-devel@gnu.org; Fri, 26 Feb 2016 02:27:33 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 17EC2205A1 for ; Fri, 26 Feb 2016 02:27:32 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 26 Feb 2016 02:27:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Scr/KUye29RS+4toop7aGiKJIKc =; b=Uj5jzkt2TmKUJM36eQXUkefEc/6it8uWfUh/2SnTAHBGsFJLsIwoRJYpt4v K/204XPnh6dWqinuhpQMIYg1JQnyeZVTRDMvGWo69iaBoYjGLjMsLFX8sWNK/5kn rxb1gtFJgUq7Ti4ITN0LScsi/t/8wzLOdooCMS8Rp3JliQ+w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Scr/KUye29RS+4t oop7aGiKJIKc=; b=kfGl0PDEjg7yVCkxLV1kyD8fCFZ8tveMERrms+SwSPWoo0R 9GvhvaXSDtK+F08FF6s0QcdE5ZTrBFQYIDU+OsuBO0zXxlPtYaz1DCizCQgogf6u 7L2dy2pNaqXiS09oFbQlR+DJBSAqbJ7TWnJHNGt+hYn/dSDoYV5+flCvhTlo= X-Sasl-enc: qqjWriHB7ILCwMgMW/sq0+V8aBIdGidlEQzAOd0VjwC7 1456471649 Original-Received: from [33.232.119.252] (unknown [172.56.7.217]) by mail.messagingengine.com (Postfix) with ESMTPA id A7661680109; Fri, 26 Feb 2016 02:27:28 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: <83oab4g407.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.29 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:200689 Archived-At: On February 25, 2016 8:15:52 AM PST, Eli Zaretskii wrote: >> From: Dima Kogan >> Date: Wed, 24 Feb 2016 17:32:01 -0800 >> >> I've been thinking of ways to make some fancier aspects of isearch >and >> hi-lock work better, specifically, the way we handle the different >> modes: case-fold, char-fold, lax-whitespace, etc. >> >> >> The best solution I can think of to clean this up is also the most >> intrusive: adding support for pcre-style embedded modifiers to >> activate/deactivate the modes. >> >> So for instance "\\(?i\\)asdf" would be interpreted as a case-folding >> regex regardless of the value of case-fold-search. > >I hope you are not proposing this as a replacement for the M-s >toggles, because if so, I'm very much opposed. This proposal is concerned with the internals of the regex parser only, so not trying to break M-s toggles. >> As an example, currently hi-lock generates a complicated-looking >regex >> to emulate char-folding and case-folding. If we supported the >modifiers, >> this change would simply be a prepend of "\\(?i\\)" or whatever other >> modes we want. This is simple and expected to be bug-free on the >hi-lock >> level. Bugs such as hi-lock not supporting char-fold and case-fold at >> the same time would not happen. > >They will also not happen once character-folding is implemented via >translation tables, instead of regular expressions. The current >implementation will go away at some point (one hopes). OK, that's good to hear, but char-fold isn't causing all the funkyness here. I'm looking at importing the regex test suite in glibc to emacs. Would this be possible even if the copyright holders of those tests haven't assigned their work to the fsf? These are tests and not part of emacs on some level, so would that make it ok?