From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Unquoted special characters in regexps Date: Mon, 06 Mar 2006 08:41:33 +0100 Message-ID: <440BE7AD.8000007@gmx.at> References: <4400AD8E.5050001@gmx.at> <4400BBB1.2050800@gmx.at> <200602252213.k1PMDBP24413@raven.dms.auburn.edu> <4401A98D.3070809@gmx.at> <4401E0F2.7030800@gmx.at> <4401FCBA.1070206@gmx.at> <200602280044.k1S0iHG07279@raven.dms.auburn.edu> <200603050337.k253brP03395@raven.dms.auburn.edu> <440AC722.7020009@gmx.at> <200603051532.k25FWR011484@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1141691265 23814 80.91.229.2 (7 Mar 2006 00:27:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2006 00:27:45 +0000 (UTC) Cc: ttn@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 07 01:27:44 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FGQ3C-0005bY-Eu for ged-emacs-devel@m.gmane.org; Tue, 07 Mar 2006 01:27:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FGQ3B-0002kC-IG for ged-emacs-devel@m.gmane.org; Mon, 06 Mar 2006 19:27:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FGOrb-00039k-Sq for emacs-devel@gnu.org; Mon, 06 Mar 2006 18:11:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FGOrW-00037S-Vi for emacs-devel@gnu.org; Mon, 06 Mar 2006 18:11:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FGK07-0004iu-5t for emacs-devel@gnu.org; Mon, 06 Mar 2006 13:00:07 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1FGB0n-0005nW-Hc for emacs-devel@gnu.org; Mon, 06 Mar 2006 03:24:13 -0500 Original-Received: (qmail invoked by alias); 06 Mar 2006 08:21:44 -0000 Original-Received: from N934P000.adsl.highway.telekom.at (EHLO [62.47.60.160]) [62.47.60.160] by mail.gmx.net (mp032) with SMTP; 06 Mar 2006 09:21:44 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Luc Teirlinck In-Reply-To: <200603051532.k25FWR011484@raven.dms.auburn.edu> X-Y-GMX-Trusted: 0 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:51305 Archived-At: > Note how easy this is. Unlike for, say \\( you do not even have to > keep track of which `[' matches which `]', because there is no > nesting. All you need to keep track of is whether you are inside or > outside a character alternative. I do not have any problems matching `[' with `]' when regexps are written cleanly. I do have problems when `]', `\]', or `\\]' get mixed up as in the `gud-jdb-marker-filter' bug. > You are making things difficult by treating `[' and `]' in regexps as > if they had the usual open-close parentheses syntax, like \\( and \\). > They do *not* and that is the cause of all your misunderstandings. In > "[1[2]3]" the first `]' closes the first `[' and "balance" makes no > sense for the other `[' and `]'. If `[' and `]' had the usual open-close > parentheses syntax, the 2 would be inside a nested character > alternative, two levels deep. But there is no such thing as nested > character alternatives, because, in regexps, `[' and `]' do not have > the usual open-close parentheses syntax (unlike, say, in Lisp vectors). We have been comparing character alternatives with strings. Elisp strings don't nest.