* flush-lines and regexp problems with emacs 22.0.x
@ 2007-01-16 4:03 Vincent Lefevre
2007-01-17 2:18 ` Richard Stallman
0 siblings, 1 reply; 5+ messages in thread
From: Vincent Lefevre @ 2007-01-16 4:03 UTC (permalink / raw)
Hi,
I get strange results with flush-lines. The first one may be due to
a lack of clear documentation, but I'm pretty sure the second one is
a bug.
The following tests have been done with GNU Emacs 22.0.50.1 under
Mac OS X (MacPorts) and with GNU Emacs 22.0.92.1 under GNU/Linux
(Debian package emacs-snapshot).
1. Consider the following file:
--------------------
> test 1
> foo
blah
> test 2
> foo
> foobar
blah
--------------------
where the cursor is a the top. I evaluate (with "M-:") the following:
(flush-lines "^\\(> \n\\)*> foo\n\\(\n?> .*\\)*")
and I get:
--------------------
> test 1
blah
> test 2
blah
--------------------
instead of
--------------------
> test 1
blah
> test 2
blah
--------------------
I'd say that the blank line shouldn't be deleted because nothing is
matched on it. But the end point is on this line, so I'm not sure.
The flush-lines documentation is not clear about that.
2. Now consider the following file:
--------------------
> test 1
> foo
blah
> test 2
> foo
> bar
> foobar
blah
> test 3
> foobar
blah
--------------------
(flush-lines "^\\(> \n\\)*> foo$\\(\n> .*\\)*") has no effect on it.
(flush-lines "^\\(> \n\\)*> foo\\($\\|\\(\n> .*\\)+\\)") doesn't have
any effect either, but if I permute the both sides of the "|", i.e.
(flush-lines "^\\(> \n\\)*> foo\\(\\(\n> .*\\)+\\|$\\)")
then I get:
--------------------
> test 1
blah
> test 2
blah
> test 3
> foobar
blah
--------------------
as expected.
Regards,
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flush-lines and regexp problems with emacs 22.0.x
2007-01-16 4:03 flush-lines and regexp problems with emacs 22.0.x Vincent Lefevre
@ 2007-01-17 2:18 ` Richard Stallman
2007-01-17 4:26 ` Vincent Lefevre
0 siblings, 1 reply; 5+ messages in thread
From: Richard Stallman @ 2007-01-17 2:18 UTC (permalink / raw)
Cc: bug-gnu-emacs
I don't think these are bugs. $ is only special in certain contexts;
in other contexts it matches a $ character. That may be the case of
your second puzzler.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flush-lines and regexp problems with emacs 22.0.x
2007-01-17 2:18 ` Richard Stallman
@ 2007-01-17 4:26 ` Vincent Lefevre
0 siblings, 0 replies; 5+ messages in thread
From: Vincent Lefevre @ 2007-01-17 4:26 UTC (permalink / raw)
On 2007-01-16 21:18:08 -0500, Richard Stallman wrote:
> I don't think these are bugs. $ is only special in certain contexts;
> in other contexts it matches a $ character. That may be the case of
> your second puzzler.
Does this mean that the context changes when one swaps the both sides
of a "\|" in a regexp?
If $ depends on the context, it should be clearly documented.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flush-lines and regexp problems with emacs 22.0.x
@ 2007-01-17 8:01 martin rudalics
2007-01-17 8:31 ` Vincent Lefevre
0 siblings, 1 reply; 5+ messages in thread
From: martin rudalics @ 2007-01-17 8:01 UTC (permalink / raw)
Cc: help-gnu-emacs
> I'd say that the blank line shouldn't be deleted because nothing is
> matched on it. But the end point is on this line, so I'm not sure.
> The flush-lines documentation is not clear about that.
`flush-lines' deletes everything from the beginning of the line where
the match starts to the beginning of the line following the end of the
match. I think the documentation of `flush-lines' should be improved in
this regard.
> (flush-lines "^\\(> \n\\)*> foo$\\(\n> .*\\)*") has no effect on it.
This is explained in the manuals:
For historical compatibility reasons, `$' can be used only at the
end of the regular expression, or before `\)' or `\|'.
> (flush-lines "^\\(> \n\\)*> foo\\($\\|\\(\n> .*\\)+\\)") doesn't have
> any effect either,
This is strange, it does match
> foo
on my system, hence it should flush that line. Please recheck.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: flush-lines and regexp problems with emacs 22.0.x
2007-01-17 8:01 martin rudalics
@ 2007-01-17 8:31 ` Vincent Lefevre
0 siblings, 0 replies; 5+ messages in thread
From: Vincent Lefevre @ 2007-01-17 8:31 UTC (permalink / raw)
Cc: help-gnu-emacs
On 2007-01-17 09:01:04 +0100, martin rudalics wrote:
> > (flush-lines "^\\(> \n\\)*> foo\\($\\|\\(\n> .*\\)+\\)") doesn't have
> > any effect either,
>
> This is strange, it does match
>
> > foo
>
> on my system, hence it should flush that line. Please recheck.
Yes, you're right, I mixed up with another regexp.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-01-17 8:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-16 4:03 flush-lines and regexp problems with emacs 22.0.x Vincent Lefevre
2007-01-17 2:18 ` Richard Stallman
2007-01-17 4:26 ` Vincent Lefevre
-- strict thread matches above, loose matches on Subject: below --
2007-01-17 8:01 martin rudalics
2007-01-17 8:31 ` Vincent Lefevre
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.