From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Matches for multiline regexps Date: Sun, 19 Jun 2005 20:57:18 -0500 (CDT) Message-ID: <200506200157.j5K1vIK12877@raven.dms.auburn.edu> References: <200506160140.j5G1eFJ26066@raven.dms.auburn.edu> <200506170326.j5H3Qxc01563@raven.dms.auburn.edu> <200506180248.j5I2mW504853@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1119232486 24275 80.91.229.2 (20 Jun 2005 01:54:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2005 01:54:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 03:54:37 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DkBUi-0002ar-LW for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2005 03:54:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DkBaq-0000p5-HO for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2005 22:00:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DkBae-0000ol-HW for emacs-devel@gnu.org; Sun, 19 Jun 2005 22:00:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DkBad-0000o9-3j for emacs-devel@gnu.org; Sun, 19 Jun 2005 22:00:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DkBac-0000nK-Rc for emacs-devel@gnu.org; Sun, 19 Jun 2005 22:00:42 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DkBbD-0003tv-NF; Sun, 19 Jun 2005 22:01:19 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j5K1wgCK019118; Sun, 19 Jun 2005 20:58:43 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j5K1vIK12877; Sun, 19 Jun 2005 20:57:18 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sat, 18 Jun 2005 23:50:51 -0400) 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:39137 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39137 Richard Stallman wrote: The code appears to be designed for uniline matches. However, the Emacs 21 behavior you described is not desirable behavior. It was merely how things happened to be. Returning to that should not be the goal. I took a closer look at the current occur code. It definitely does not make the slightest attempt at handling regexps that can match more than one line. The fact that the regexp does not match a newline seems to be a basic assumption made in the current occur code. The fact that it seemed to try (but not succeed) to handle regexps that could match newlines was merely an optical illusion. The current occur code does not make any attempt to handle overlapping matches either. The fact that it seemed to try was again an optical illusion. The current occur code completely fails in several respects for regexps that can match newlines. This has been the situation for more than three years now in CVS. The fact that no bug reports were ever filed shows that nobody using Emacs CVS has attempted to use occur for a regexp that can match newlines in more than three years. The only reason I tried was out of curiosity, to check how it would handle overlapping matches. Making occur handle multiline matches (which it could do in 21.3, but it apparently lost that ability when occur got completely rewritten more than three years ago), as well as overlapping matches (which is tricky and which occur never could) and change the way context lines are handled seems to require a complete rewrite of the current occur machinery into something much more complex. That seems to be a major task and I currently to not have the time to take it on. Experience of the last three plus years seems to show that nobody appears to be interested in such functionality anyway. Maybe somebody more familiar with, and more heavily interested in, occur than I am might be willing to take on the task. (I merely stumbled on the problem by rereading man/search.texi, which was extensively changed since I last read it.) I will take care of flush-lines and keep-lines, however. I am nearly ready with it and only need to double check some things. Sincerely, Luc.