From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Match empty string at begin/end of symbol Date: Wed, 04 Jul 2018 22:22:15 +0300 Message-ID: <83zhz6n6vs.fsf@gnu.org> References: <20180704114346.73df0142@gauss> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530732047 24602 195.159.176.226 (4 Jul 2018 19:20:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 19:20:47 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jul 04 21:20:43 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fanKS-0006Fc-HT for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 21:20:40 +0200 Original-Received: from localhost ([::1]:48917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fanMY-0008Pr-7B for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 15:22:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fanM6-0008Pl-4E for help-gnu-emacs@gnu.org; Wed, 04 Jul 2018 15:22:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fanM3-0002Hb-09 for help-gnu-emacs@gnu.org; Wed, 04 Jul 2018 15:22:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fanM2-0002HP-Tm for help-gnu-emacs@gnu.org; Wed, 04 Jul 2018 15:22:18 -0400 Original-Received: from [176.228.60.248] (port=2796 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fanM1-00079e-Vq for help-gnu-emacs@gnu.org; Wed, 04 Jul 2018 15:22:18 -0400 In-reply-to: <20180704114346.73df0142@gauss> (message from Joe Riel on Wed, 4 Jul 2018 11:43:46 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:117348 Archived-At: > Date: Wed, 4 Jul 2018 11:43:46 -0700 > From: Joe Riel > > The regular expressions '\_<' and '\_>' > seem to be broken in Emacs 25.1.1. Consider > > (let ((str "3+ab")) > (and (string-match "\\<[a-zA-Z][a-zA-Z0-9]*" str) > (match-string 0 str))) > > That returns "ab", as expected. Change the "\\<" to "\\_<" > and it no longer matches. Why not? > > (let ((str "3+ab")) > (and (string-match "\\_<[a-zA-Z][a-zA-Z0-9]*" str) > (match-string 0 str))) The result of the last form depends on the major mode of the buffer where (or in whose minibuffer) you evaluate it. If it's Lisp or its derivatives, it indeed should not match because a Lisp symbol can legitimately be named "3+ab", and so "ab" is not at a symbol boundary. But if you try the same in a buffer whose major mode is C Mode, you surely get a match, because '+' is not a symbol-constituent character in C. IOW, I don't think there's a bug here. It's behaving as intended.