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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2017-06-12, Bruce Mardle <marblypup@yahoo.co.uk> wrote:

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 12 June 2017 08:25:03 UTC+1, Julian Bradfield wrote:

On 2017-06-12, Bruce Mardle <marblypup@yahoo.co.uk> wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On Monday, 12 June 2017 08:25:03 UTC+1, Julian Bradfield wrote:

On 2017-06-12, Bruce Mardle <marblypup@yahoo.co.uk> wrote:

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)

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2017-06-13, Bruce Mardle <marblypup@yahoo.co.uk> wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 13 June 2017 17:52:02 UTC+1, Michael Heerdegen wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Bruce Mardle <marblypup@yahoo.co.uk>
| On Tuesday, 13 June 2017 17:52:02 UTC+1, Michael Heerdegen wrote:
| > Bruce Mardle <marblypup@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'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, 14 June 2017 13:42:55 UTC+1, Ralf Fassel wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ralf Fassel <ralfixx@gmx.de> writes:

* Bruce Mardle <marblypup@yahoo.co.uk>
| On Tuesday, 13 June 2017 17:52:02 UTC+1, Michael Heerdegen wrote:
| > Bruce Mardle <marblypup@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")))

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?

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Ben Bacarisse <ben.usenet@bsb.me.uk>
| Ralf Fassel <ralfixx@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'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, 14 June 2017 18:18:20 UTC+1, Ralf Fassel wrote:

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

- (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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

<snip>

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

<snip>

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).

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 15 June 2017 01:59:59 UTC+1, Ben Bacarisse wrote:

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

<snip>

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

<snip>

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)