From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: abela@chalmers.se, 31796@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Tue, 01 Dec 2020 17:46:19 +0200 [thread overview]
Message-ID: <83k0u1il6c.fsf@gnu.org> (raw)
In-Reply-To: <E1kjy5E-00046B-7R@fencepost.gnu.org> (message from Richard Stallman on Tue, 01 Dec 2020 00:20:12 -0500)
> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, abela@chalmers.se, 31796@debbugs.gnu.org
> Date: Tue, 01 Dec 2020 00:20:12 -0500
>
> Can people think of a new feature that would be easy to add to GNU grep
> that would make it easy for Dired to handle all cases correctly?
Yes: it should detect encoding of each input file (and have a way of
letting the user specify encoding for each file), convert the file's
contents to some internal encoding (probably UTF-8), then report the
hits encoded in UTF-8, regardless of the file's original encoding (and
regardless of the current locale's codeset).
> I don't know what the problem is, but if it has to do with parsing the
> grep output, here's an idea: an option to tell GNU grep to use quoting
> on file names and the match strings, Perhaps in the same way GNU ls
> does.
The problem is not with file names, it's with the matches. But since
you mention it: Grep should, in this new mode, report file names also
recoded into UTF-8. In a word, it should arrange for its output be in
a single encoding known in advance, so that front ends like Emacs
won't need to guess the encoding.
> Another idea is an option to output numerical byte positions in the
> file instead of the lines that are matched. Emacs can feed those byte
> positions into byte-to-position to convert them into buffer positions.
AFAIU, there's already such an option: -b. However, byte-to-position
works only with UTF-8 encoded files; we need filepos-to-bufferpos
(which requires to know the file's encoding, so we are back at the
same problem).
next prev parent reply other threads:[~2020-12-01 15:46 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 18:58 bug#31796: 26.1; dired-do-find-regexp-and-replace fails to find multiline regexps Žygimantas Bruzgys
2018-06-12 10:17 ` Noam Postavsky
2020-11-23 21:25 ` Dmitry Gutov
2020-11-23 9:09 ` bug#31796: 27.1; " Andreas Abel
2020-11-23 15:23 ` Eli Zaretskii
2020-11-23 16:16 ` Drew Adams
2020-11-23 21:22 ` Dmitry Gutov
2020-11-24 19:28 ` Juri Linkov
2020-11-24 20:12 ` Drew Adams
2020-11-25 7:31 ` Juri Linkov
2020-11-25 17:37 ` Drew Adams
2020-11-24 20:19 ` Eli Zaretskii
2020-11-24 20:31 ` Juri Linkov
2020-11-24 20:51 ` Drew Adams
2020-11-24 21:07 ` Eli Zaretskii
2020-11-25 7:28 ` Juri Linkov
2020-11-25 15:48 ` Eli Zaretskii
2020-11-25 20:18 ` Juri Linkov
2020-11-25 20:30 ` Eli Zaretskii
2020-11-29 2:30 ` Dmitry Gutov
2020-11-29 15:22 ` Eli Zaretskii
2020-11-23 21:28 ` Dmitry Gutov
2020-11-23 23:49 ` Andreas Abel
2020-11-24 0:13 ` Dmitry Gutov
2020-11-24 1:19 ` Dmitry Gutov
2020-11-24 15:16 ` Eli Zaretskii
2020-11-24 15:43 ` Dmitry Gutov
2020-11-24 16:35 ` Eli Zaretskii
2020-11-24 19:43 ` Dmitry Gutov
2020-11-24 20:16 ` Eli Zaretskii
2020-11-30 2:25 ` Dmitry Gutov
2020-11-30 8:49 ` Juri Linkov
2020-12-01 2:21 ` Dmitry Gutov
2020-12-01 8:39 ` Juri Linkov
2020-12-03 2:46 ` Dmitry Gutov
2020-12-06 21:00 ` Juri Linkov
2020-12-16 3:00 ` Dmitry Gutov
2020-12-16 20:32 ` Juri Linkov
2020-12-17 0:40 ` Dmitry Gutov
2020-11-30 15:30 ` Eli Zaretskii
2020-11-30 15:39 ` Jean Louis
2020-11-30 16:36 ` Eli Zaretskii
2020-11-30 15:42 ` Jean Louis
2020-12-01 1:23 ` Dmitry Gutov
2020-12-01 8:36 ` Juri Linkov
2020-12-01 15:20 ` Dmitry Gutov
2020-12-01 1:24 ` Dmitry Gutov
2020-12-01 5:20 ` Richard Stallman
2020-12-01 15:46 ` Eli Zaretskii [this message]
2020-12-02 4:26 ` Richard Stallman
2020-12-02 14:56 ` Eli Zaretskii
2020-12-02 17:17 ` Dmitry Gutov
2020-12-02 17:39 ` Eli Zaretskii
2020-12-02 17:43 ` Dmitry Gutov
2020-12-02 17:47 ` Eli Zaretskii
2020-12-03 5:26 ` Richard Stallman
2020-12-03 2:23 ` Dmitry Gutov
2020-11-24 19:29 ` Juri Linkov
2020-11-24 19:39 ` Dmitry Gutov
[not found] <<CADy8Bt=f=LOE6ODLhhW7ZS6qXRQCzd15Hd0eFKVO8qok98ni8w@mail.gmail.com>
[not found] ` <<10120030-8b8d-b702-add4-8f099f934ed5@chalmers.se>
[not found] ` <<91c98791-9df2-43ee-9aac-205c5b0de9c2@default>
[not found] ` <<87blfm6922.fsf@mail.linkov.net>
[not found] ` <<838saqtsm9.fsf@gnu.org>
2020-11-24 20:32 ` Drew Adams
[not found] ` <<87mtz64htw.fsf@mail.linkov.net>
[not found] ` <<831rgitqe2.fsf@gnu.org>
2020-11-24 21:35 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83k0u1il6c.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=31796@debbugs.gnu.org \
--cc=abela@chalmers.se \
--cc=dgutov@yandex.ru \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).