GNU bug report logs - #34520
delete-matching-lines should report how many lines it deleted

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34520 in the body.
You can then email your comments to 34520 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: delete-matching-lines should report how many lines it deleted
Date: Mon, 18 Feb 2019 08:35:08 +0800

delete-matching-lines is an alias for ‘flush-lines’ in ‘replace.el’.

It works great... or does it? Can't often tell. That's because well,
if there are matching lines off the screen, you won't really know, so
you have to go down there to have a look... and well, need eagle eyes
often too depending on the pattern and how many similar lines there
still are.

Got an idea!: Simply keep a count of how many lines were deleted, and
report that in the minibuffer, if using interactively.

What if there were no matching lines?
Then say
Deleted 0 matching lines.
Or beep "No matching lines!"

Try this with matching lines all below the visible part of the buffer:
C-x h [mark-whole-buffer]
M-x delete-matching-lines zzzzz

See the feeling (felt nothing, did it work in the first place one wonders?)

Message #8 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Borkowski <mbork <at> mbork.pl>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34520 <at> debbugs.gnu.org
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Mon, 18 Feb 2019 07:06:05 +0100

On 2019-02-18, at 01:35, 積丹尼 Dan Jacobson <jidanni <at> jidanni.org> wrote:

> delete-matching-lines is an alias for ‘flush-lines’ in ‘replace.el’.
>
> It works great... or does it? Can't often tell. That's because well,
> if there are matching lines off the screen, you won't really know, so
> you have to go down there to have a look... and well, need eagle eyes
> often too depending on the pattern and how many similar lines there
> still are.
>
> Got an idea!: Simply keep a count of how many lines were deleted, and
> report that in the minibuffer, if using interactively.

I like this a lot.  I use delete-matching-lines (and
delete-non-matching-lines) a lot, both would be greatly enhanced with
such a feature.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Message #11 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34520 <at> debbugs.gnu.org
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Wed, 27 Feb 2019 23:36:53 +0200

[Message part 1 (text/plain, inline)]

> Got an idea!: Simply keep a count of how many lines were deleted, and
> report that in the minibuffer, if using interactively.

Good idea, this will bring deleting the lines under control:

[flush-lines-count.patch (text/x-diff, inline)]

diff --git a/lisp/replace.el b/lisp/replace.el
index b482d76afc..c3d8278936 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -953,7 +953,10 @@ flush-lines
 
 If a match is split across lines, all the lines it lies in are deleted.
 They are deleted _before_ looking for the next match.  Hence, a match
-starting on the same line at which another match ended is ignored."
+starting on the same line at which another match ended is ignored.
+
+Return the number of deleted lines.  When called interactively,
+also print the number."
   (interactive
    (progn
      (barf-if-buffer-read-only)
@@ -968,7 +971,8 @@ flush-lines
       (setq rstart (point)
 	    rend (point-max-marker)))
     (goto-char rstart))
-  (let ((case-fold-search
+  (let ((count 0)
+        (case-fold-search
 	 (if (and case-fold-search search-upper-case)
 	     (isearch-no-upper-case-p regexp t)
 	   case-fold-search)))
@@ -978,9 +982,13 @@ flush-lines
 	(delete-region (save-excursion (goto-char (match-beginning 0))
 				       (forward-line 0)
 				       (point))
-		       (progn (forward-line 1) (point))))))
-  (set-marker rend nil)
-  nil)
+		       (progn (forward-line 1) (point)))
+        (setq count (1+ count))))
+    (set-marker rend nil)
+    (when interactive (message "Deleted %d matching line%s"
+			       count
+			       (if (= count 1) "" "s")))
+    count))
 
 
 (defun how-many (regexp &optional rstart rend interactive)

Message #14 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 34520 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Thu, 28 Feb 2019 05:34:13 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 27 Feb 2019 23:36:53 +0200
> Cc: 34520 <at> debbugs.gnu.org
> 
> +    (when interactive (message "Deleted %d matching line%s"
> +			       count
> +			       (if (= count 1) "" "s")))
> +    count))

The concatenation of "s" trick works only in English, so please avoid
that.

This needs NEWS and manual updates.

Thanks.

Message #19 received at 34520-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34520-done <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Thu, 28 Feb 2019 23:33:10 +0200

>> +    (when interactive (message "Deleted %d matching line%s"
>> +			       count
>> +			       (if (= count 1) "" "s")))
>> +    count))
>
> The concatenation of "s" trick works only in English, so please avoid
> that.

Ok, waiting for the times when ‘gettext’ will arrive to Emacs.

> This needs NEWS and manual updates.

Done.

Message #22 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 34520 <at> debbugs.gnu.org, jidanni <at> jidanni.org, juri <at> linkov.net
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Thu, 28 Feb 2019 22:59:17 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Ok, waiting for the times when ‘gettext’ will arrive to Emacs.

It would be very desirable to make Emacs support gettext-style
translations.  I have a feeling that it can't use the same
code as gettext -- but with all of Emacs's other facilities,
I think that transposing the useful part of gettext into
Emacs won't be a big job.

Would someone like to do this?


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #25 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: 34520 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Sat, 02 Mar 2019 22:55:52 +0200

>   > Ok, waiting for the times when ‘gettext’ will arrive to Emacs.
>
> It would be very desirable to make Emacs support gettext-style
> translations.  I have a feeling that it can't use the same
> code as gettext -- but with all of Emacs's other facilities,
> I think that transposing the useful part of gettext into
> Emacs won't be a big job.
>
> Would someone like to do this?

Emacs can do much better job of text translation than gettext.

It's easy to translate text transparently to the caller,
i.e. without changing the caller code at all, by adding
a new intermediate layer to some text output functions
that will translate their string arguments to the
language of the default language environment.

Here is an experimental but extensible implementation
that handles the case of formatting the recently added message
taking into account grammatical number of its argument:

  (defvar i18n-translations-hash (make-hash-table :test 'equal))

  (defun i18n-add-translation (_language-environment from to)
    (puthash from to i18n-translations-hash))

  (i18n-add-translation
   "English"
   "Deleted %d matching lines"
   (lambda (format-string count)
     (if (= count 1)
         "Deleted %d matching line"
         "Deleted %d matching lines")))

  (defun i18n-get-translation (format-string &rest args)
    (pcase (gethash format-string i18n-translations-hash)
      ((and (pred functionp) f) (apply f format-string args))
      ((and (pred stringp) s) s)
      (_ format-string)))

  (advice-add 'message :around
              (lambda (orig-fun format-string &rest args)
                (apply orig-fun (apply 'i18n-get-translation format-string args) args))
              '((name . message-i18n)))

In addition to translating format strings of the function 'message',
doing the same for more text output functions like 'describe-function',
'describe-variable' and 'menu-item' in 'define-key' would cover most
of the internationalization needs.

Message #28 received at 34520 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Richard Stallman <rms <at> gnu.org>
Cc: 34520 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: RE: bug#34520: delete-matching-lines should report how many lines it
 deleted
Date: Sat, 2 Mar 2019 15:39:37 -0800 (PST)

> >   > Ok, waiting for the times when ‘gettext’ will arrive to Emacs.
> >
> > It would be very desirable to make Emacs support gettext-style
> > translations.  I have a feeling that it can't use the same
> > code as gettext -- but with all of Emacs's other facilities,
> > I think that transposing the useful part of gettext into
> > Emacs won't be a big job.
> >
> > Would someone like to do this?
> 
> Emacs can do much better job of text translation than gettext.
> 
> It's easy to translate text transparently to the caller,
> i.e. without changing the caller code at all, by adding
> a new intermediate layer to some text output functions
> that will translate their string arguments to the
> language of the default language environment.

Is this bug thread really the place for such a discussion?
Don't you want to create a dedicated emacs-devel discussion
for this instead (restarting from the beginning)?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.