^$

[Bruce Mardle]

Hi, everyone.
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches but I KNOW there are a lot more blank lines than that.
Eventually it occurred to me to count-matches with ^.+$
That returned the correct number of non-blank lines (551).

What was wrong with my ^$ ?

I thought it might be because the file was using 'DOS' coding but I got the same result when I changed it to 'unix' and got rid of each ^M.

[Julian Bradfield]

Post by Bruce Mardle
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches but I KNOW there are a lot more blank lines than that.

Are you sure none of the blank lines have spacess in them?
Was point at the start of the file when you did it?

[Bruce Mardle]

Post by Julian Bradfield

Post by Bruce Mardle
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches but I KNOW there are a lot more blank lines than that.

Are you sure none of the blank lines have spacess in them?
Was point at the start of the file when you did it?

Thanks for the reply. Yes (I wrote a C program to count them) and yes.

[Julian Bradfield]

Post by Bruce Mardle
Thanks for the reply. Yes (I wrote a C program to count them) and yes.

ok, then it's impossible to give any further advice without having
a copy of the file and the exact emacs version you were using.

[Ben Bacarisse]

Post by Bruce Mardle

Post by Julian Bradfield

Post by Bruce Mardle
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches
but I KNOW there are a lot more blank lines than that.

Are you sure none of the blank lines have spacess in them?
Was point at the start of the file when you did it?

Thanks for the reply. Yes (I wrote a C program to count them) and yes.

Hmmm... Looks very odd to me. I just tried in a small test buffer and
I can not predict the result of M-x count-matches RET ^$ RET. Looking
at the code there seems to be a problem counting consecutive zero-length
matches but I can't yet see how it should be fixed.

(Emacs 24.5.1)

[Michael Heerdegen]

Post by Bruce Mardle
Hi, everyone.
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches
but I KNOW there are a lot more blank lines than that.
Eventually it occurred to me to count-matches with ^.+$
That returned the correct number of non-blank lines (551).
What was wrong with my ^$ ?

It seems that consecutive empty lines are counted incorrectly. Only the
first line of a group is count. Seems it's a flaw in the
implementation. I suggest to M-x report-emacs-bug.


Michael.

[Bruce Mardle]

Post by Michael Heerdegen

Post by Bruce Mardle
Hi, everyone.
Just now I wanted to count all the blank lines in a 909-line file.
I tried M-x count-matches with ^$ and it said there were 10 matches
but I KNOW there are a lot more blank lines than that.
Eventually it occurred to me to count-matches with ^.+$
That returned the correct number of non-blank lines (551).
What was wrong with my ^$ ?

It seems that consecutive empty lines are counted incorrectly. Only the
first line of a group is count. Seems it's a flaw in the
implementation. I suggest to M-x report-emacs-bug.
Michael.

Thanks to everyone who replied.
That's exactly right, Michael! I'll report it. isearch-forward-regexp treats blank lines separately with ^S

[Ralf Fassel]

* Bruce Mardle <***@yahoo.co.uk>
| On Tuesday, 13 June 2017 17:52:02 UTC+1, Michael Heerdegen wrote:
| > Bruce Mardle <***@yahoo.co.uk> writes:
| >
--<snip-snip>--
| > >
| > > What was wrong with my ^$ ?
| >
| > It seems that consecutive empty lines are counted incorrectly. Only
| > the first line of a group is count. Seems it's a flaw in the
| > implementation. I suggest to M-x report-emacs-bug.
| Thanks to everyone who replied. That's exactly right, Michael! I'll
| report it. isearch-forward-regexp treats blank lines separately with ^S

You may want to attach the patch, it's a simple paren-in-wrong-place
bug. 'count' needs to get increased every time, not only when the match
spans more than zero chars.


--- emacs/24.3/lisp/replace.el 2017/06/14 12:40:49 1.1
+++ emacs/24.3/lisp/replace.el 2017/06/14 12:41:02
@@ -804,8 +804,8 @@
(progn (setq opoint (point))
(re-search-forward regexp rend t)))
(if (= opoint (point))
- (forward-char 1)
- (setq count (1+ count))))
+ (forward-char 1))
+ (setq count (1+ count)))
(when interactive (message "%d occurrence%s"
count
(if (= count 1) "" "s")))

HTH
R'

[Bruce Mardle]

Post by Ralf Fassel
You may want to attach the patch, it's a simple paren-in-wrong-place
bug. 'count' needs to get increased every time, not only when the match
spans more than zero chars.
--- emacs/24.3/lisp/replace.el 2017/06/14 12:40:49 1.1
+++ emacs/24.3/lisp/replace.el 2017/06/14 12:41:02
@@ -804,8 +804,8 @@
(progn (setq opoint (point))
(re-search-forward regexp rend t)))
(if (= opoint (point))
- (forward-char 1)
- (setq count (1+ count))))
+ (forward-char 1))
+ (setq count (1+ count)))
(when interactive (message "%d occurrence%s"
count
(if (= count 1) "" "s")))
HTH
R'

Thanks, Ralf.
FWIW, in GNU Emacs 25.2.1 the offending lines start at 986.

[Ben Bacarisse]

Post by Ralf Fassel
| >
--<snip-snip>--
| > >
| > > What was wrong with my ^$ ?
| >
| > It seems that consecutive empty lines are counted incorrectly. Only
| > the first line of a group is count. Seems it's a flaw in the
| > implementation. I suggest to M-x report-emacs-bug.
| Thanks to everyone who replied. That's exactly right, Michael! I'll
| report it. isearch-forward-regexp treats blank lines separately with ^S
You may want to attach the patch, it's a simple paren-in-wrong-place
bug. 'count' needs to get increased every time, not only when the match
spans more than zero chars.
--- emacs/24.3/lisp/replace.el 2017/06/14 12:40:49 1.1
+++ emacs/24.3/lisp/replace.el 2017/06/14 12:41:02
@@ -804,8 +804,8 @@
(progn (setq opoint (point))
(re-search-forward regexp rend t)))
(if (= opoint (point))
- (forward-char 1)
- (setq count (1+ count))))
+ (forward-char 1))
+ (setq count (1+ count)))
(when interactive (message "%d occurrence%s"
count
(if (= count 1) "" "s")))

I'm not sure it's as simple as that. I tried the same fix but did not
suggest it because it does not match my idea if blank lines and I had no
time to investigate further.

With that patch, a file containing the five hex bytes 78 0A 0A 78 0A is
reported as having three blank lines. One blank line is always counted
at the end of the buffer (unless it has zero bytes) but I'm not sure
where the others come come. Do you get the same results?

[Ralf Fassel]

* Ben Bacarisse <***@bsb.me.uk>
| Ralf Fassel <***@gmx.de> writes:
| > --- emacs/24.3/lisp/replace.el 2017/06/14 12:40:49 1.1
| > +++ emacs/24.3/lisp/replace.el 2017/06/14 12:41:02
| > @@ -804,8 +804,8 @@
| > (progn (setq opoint (point))
| > (re-search-forward regexp rend t)))
| > (if (= opoint (point))
| > - (forward-char 1)
| > - (setq count (1+ count))))
| > + (forward-char 1))
| > + (setq count (1+ count)))
| > (when interactive (message "%d occurrence%s"
| > count
| > (if (= count 1) "" "s")))
| I'm not sure it's as simple as that. I tried the same fix but did not
| suggest it because it does not match my idea if blank lines and I had no
| time to investigate further.
| With that patch, a file containing the five hex bytes 78 0A 0A 78 0A is
| reported as having three blank lines. One blank line is always counted
| at the end of the buffer (unless it has zero bytes) but I'm not sure
| where the others come come. Do you get the same results?

Yes, you're right. The logic in 'how-many' seems flawed, since it
advances point only if the match itself did not advance point.
Therefore the first match leaves point at the blank line, but since we
advanced point for the match, point stays where it is, and the blank
line is matched again and is counted twice.

The third match is the final newline at the end of the buffer which also
matches "^$". This is true also for isearch-regexp-forward, which finds
two matches (which I consider wrong, too, since the trailing newline
somehow belongs to the line before that, but this seems to be a
different story).

The following version also looks at match-beginning/match-end to
determine whether to advance point after the match, and I'll leave it to
the experts to determine whether the whole 'opoint' business in there
might go away completely.

--- replace.el 2017/06/14 17:13:35 1.1
+++ replace.el 2017/06/14 17:13:57
@@ -803,9 +803,11 @@
(while (and (< (point) rend)
(progn (setq opoint (point))
(re-search-forward regexp rend t)))
- (if (= opoint (point))
- (forward-char 1)
- (setq count (1+ count))))
+ (if (or (= opoint (point))
+ (and (= (match-beginning 0) (match-end 0))
+ (not (= (point) rend))))
+ (forward-char 1))
+ (setq count (1+ count)))
(when interactive (message "%d occurrence%s"
count
(if (= count 1) "" "s")))



HTH
R'

[Bruce Mardle]

Post by Ralf Fassel
The third match is the final newline at the end of the buffer which also
matches "^$". This is true also for isearch-regexp-forward, which finds
two matches (which I consider wrong, too, since the trailing newline
somehow belongs to the line before that, but this seems to be a
different story).

The plot thickens! FWIW, my tiny C program doesn't think there's a blank line at the end :-D

Post by Ralf Fassel
- (if (= opoint (point))
- (forward-char 1)
- (setq count (1+ count))))
+ (if (or (= opoint (point))
+ (and (= (match-beginning 0) (match-end 0))
+ (not (= (point) rend))))
+ (forward-char 1))
+ (setq count (1+ count)))

Getting better :-)
I reported the original bug and added that I thought there was a fix on comp.emacs. NOW that seems to be true (if you don't mind a bogus blank line at the end of a file). Thanks, Ben & Ralf.

[Ben Bacarisse]

Bruce Mardle <***@yahoo.co.uk> writes:

<snip>

Post by Bruce Mardle
Just now I wanted to count all the blank lines in a 909-line file.

<snip>

Post by Bruce Mardle
What was wrong with my ^$ ?

As an entirely pragmatic matter, you can count blank lines even with the
current buggy commands using ^ C-Q C-J (that's control q to quote and
control j for newline). This seems to work even in buffers with DOS
line endings (presumably they are stripped and added on reading and
writing) and it won't spuriously count the last line (unless it really
is blank).

[Bruce Mardle]

Post by Ben Bacarisse
<snip>

Post by Bruce Mardle
Just now I wanted to count all the blank lines in a 909-line file.

<snip>

Post by Bruce Mardle
What was wrong with my ^$ ?

As an entirely pragmatic matter, you can count blank lines even with the
current buggy commands using ^ C-Q C-J (that's control q to quote and
control j for newline). This seems to work even in buffers with DOS
line endings (presumably they are stripped and added on reading and
writing) and it won't spuriously count the last line (unless it really
is blank).

Good thinking, Ben!