> The current duplicating of context lines of consecutive matched lines
> is too inconvenient.
>
> Inconvenient for whom? The user, or the maintainers of occur?
For the user. grep and diff don't duplicate context lines,
for good reasons.
I can see both advantages
Could you add an item to TODO and a comment in the code
saying that occur isn't handling multiline regexps?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> The current duplicating of context lines of consecutive matched lines
> is too inconvenient.
>
> Inconvenient for whom? The user, or the maintainers of occur?
For the user. grep and diff don't duplicate context lines,
for good reasons.
> It really should work like grep or diff,
The current duplicating of context lines of consecutive matched lines
is too inconvenient.
Inconvenient for whom? The user, or the maintainers of occur?
It really should work like grep or diff, and
to join consecutive lines with their context lines into one block.
I am not nec
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. I
> When not displaying context, it should display each line that contains
> any part of one or more matches. It should not display any line more
> than once.
>
> When context lines are specified, it is less clear. One idea is to
> display each group of lines that contains a match, plus context aro
I will take a look at it, but first a decision has to be made on how
we treat overlapping matches.
When not displaying context, it should display each line that contains
any part of one or more matches. It should not display any line more
than once.
When context lines are specified, it i
Of course, in my previous message, with "overlapping matches", I meant
overlapping _multiline_ matches.
The current occur implementation treats overlapping _one-line_ matches
according to the same philosophy as the one I propose for multiline
matches, which is one further argument for my proposal.
Richard Stallman wrote:
Additional remark: from simpler examples. it appears that they are
_intended_ to be line numbers. If so, this is a bug.
Yes, it seems to be a bug in counting the line numbers. Could you fix
that too?
I will take a look at it, but first a decision has
Start with a buffer containing three lines with "11" in them and a
final newline:
11
11
11
Result of `M-x keep-lines RET 11 C-q C-j 11 RET' with point at bob:
11
11
The basic ideas of keep-lines and flush-lines don't obviously extend
to multi-line regexps. Figur
4 matches for "11
11" in buffer: bu
2:11
4:11
6:11
8:11
I could not find out from the docs what those numbers in front of the
11's are supposed to mean. They are clearly not line numbers.
Additional remark: from
Richard Stallman wrote:
`M-x occur RET 11 C-q C-j 11 RET' finds four matches (lines 1 through 4)
which seems logical to me.
`M-x how-many RET 11 C-q C-j 11 RET' (with point at bob) finds two
matches.
One function looks for lines that match, while the other finds
match
Richard Stallman wrote:
`M-x occur RET 11 C-q C-j 11 RET' finds four matches (lines 1 through 4)
which seems logical to me.
`M-x how-many RET 11 C-q C-j 11 RET' (with point at bob) finds two
matches.
One function looks for lines that match, while the other finds
match
`M-x occur RET 11 C-q C-j 11 RET' finds four matches (lines 1 through 4)
which seems logical to me.
`M-x how-many RET 11 C-q C-j 11 RET' (with point at bob) finds two matches.
One function looks for lines that match, while the other finds
matches, so it is natural that they may differ
Or does occur have problems with multiline regexps?
In my previous example buffer:
11
11
11
11
11
`M-x occur RET 11 C-q C-j 11 RET' produces the following *Occur*
buffer:
4 matches for "11
11" in buffer: bu
2:11
4:11
6:11
8:11
I could not find out from the docs what tho
`query-replace' follows the `how-many' algorithm. If you do not
replace the match on line one, it does not offer to replace the match
on line two in the same example buffer:
11
11
11
11
11
So it does seem that occur is the one with exceptional behavior.
Things should be unambiguous for regexps
There are some inconsistencies between `occur' and friends on the one
hand and `how-many', `flush-lines' and `keep-lines' on the other hand,
in as far as matches for multiline regexps are concerned.
In a buffer containing five lines all containing "11":
11
11
11
11
17 matches
Mail list logo
