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

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

[積丹尼 Dan Jacobson]

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

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

[Marcin Borkowski]

On 2019-02-18, at 01:35, 積丹尼 Dan Jacobson <jidanni@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

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: flush-lines-count.patch --]
[-- Type: text/x-diff, Size: 1426 bytes --]

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)

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 27 Feb 2019 23:36:53 +0200
> Cc: 34520@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.

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

[Juri Linkov]

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

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

[Richard Stallman]

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

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

[Juri Linkov]

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

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

[Drew Adams]

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