* bug#34520: delete-matching-lines should report how many lines it deleted
@ 2019-02-18 0:35 積丹尼 Dan Jacobson
2019-02-18 6:06 ` Marcin Borkowski
2019-02-27 21:36 ` Juri Linkov
0 siblings, 2 replies; 8+ messages in thread
From: 積丹尼 Dan Jacobson @ 2019-02-18 0:35 UTC (permalink / raw)
To: 34520
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?)
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34520: delete-matching-lines should report how many lines it deleted
2019-02-18 0:35 bug#34520: delete-matching-lines should report how many lines it deleted 積丹尼 Dan Jacobson
@ 2019-02-18 6:06 ` Marcin Borkowski
2019-02-27 21:36 ` Juri Linkov
1 sibling, 0 replies; 8+ messages in thread
From: Marcin Borkowski @ 2019-02-18 6:06 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 34520
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34520: delete-matching-lines should report how many lines it deleted
2019-02-18 0:35 bug#34520: delete-matching-lines should report how many lines it deleted 積丹尼 Dan Jacobson
2019-02-18 6:06 ` Marcin Borkowski
@ 2019-02-27 21:36 ` Juri Linkov
2019-02-28 3:34 ` Eli Zaretskii
1 sibling, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2019-02-27 21:36 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 34520
[-- 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)
^ permalink raw reply related [flat|nested] 8+ messages in thread* bug#34520: delete-matching-lines should report how many lines it deleted
2019-02-27 21:36 ` Juri Linkov
@ 2019-02-28 3:34 ` Eli Zaretskii
2019-02-28 21:33 ` Juri Linkov
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2019-02-28 3:34 UTC (permalink / raw)
To: Juri Linkov; +Cc: 34520, jidanni
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34520: delete-matching-lines should report how many lines it deleted
2019-02-28 3:34 ` Eli Zaretskii
@ 2019-02-28 21:33 ` Juri Linkov
2019-03-01 3:59 ` Richard Stallman
0 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2019-02-28 21:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 34520-done, jidanni
>> + (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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34520: delete-matching-lines should report how many lines it deleted
2019-02-28 21:33 ` Juri Linkov
@ 2019-03-01 3:59 ` Richard Stallman
2019-03-02 20:55 ` Juri Linkov
0 siblings, 1 reply; 8+ messages in thread
From: Richard Stallman @ 2019-03-01 3:59 UTC (permalink / raw)
To: Juri Linkov; +Cc: juri, 34520, jidanni
[[[ 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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#34520: delete-matching-lines should report how many lines it deleted
2019-03-01 3:59 ` Richard Stallman
@ 2019-03-02 20:55 ` Juri Linkov
2019-03-02 23:39 ` Drew Adams
0 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2019-03-02 20:55 UTC (permalink / raw)
To: Richard Stallman; +Cc: 34520, jidanni
> > 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.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#34520: delete-matching-lines should report how many lines it deleted
2019-03-02 20:55 ` Juri Linkov
@ 2019-03-02 23:39 ` Drew Adams
0 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2019-03-02 23:39 UTC (permalink / raw)
To: Juri Linkov, Richard Stallman; +Cc: 34520, jidanni
> > > 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)?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-03-02 23:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-18 0:35 bug#34520: delete-matching-lines should report how many lines it deleted 積丹尼 Dan Jacobson
2019-02-18 6:06 ` Marcin Borkowski
2019-02-27 21:36 ` Juri Linkov
2019-02-28 3:34 ` Eli Zaretskii
2019-02-28 21:33 ` Juri Linkov
2019-03-01 3:59 ` Richard Stallman
2019-03-02 20:55 ` Juri Linkov
2019-03-02 23:39 ` Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).