[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What does Emacs on w32 know that grep can't figure out?

From: Lennart Borgman
Subject: Re: What does Emacs on w32 know that grep can't figure out?
Date: Tue, 5 Oct 2010 02:46:56 +0200

On Mon, Oct 4, 2010 at 12:50 AM, Lennart Borgman
<address@hidden> wrote:
> On Sun, Oct 3, 2010 at 9:09 PM, Eli Zaretskii <address@hidden> wrote:
>>> From: Lennart Borgman <address@hidden>
>>> Date: Sun, 3 Oct 2010 06:10:14 +0200
>>> Cc: Thierry Volpiatto <address@hidden>, address@hidden
>>>   http://technet.microsoft.com/en-us/library/dd315403.aspx
>>> it does not look as it autodetects the coding system in the file.
>> Why should it?
>> What tool does, besides Emacs?
>> It does support UTF-16.  That's the "Unicode" part of the values you
>> can submit to the -Encoding option (you need to "think MS" to get it).

This discussion seems to have stalled. So here is a summary of what we
have found:

- utf-16 is a problem since the grep program does not handle it and
utf-16 is common on w32.

- There seems to be no program we can use that autodetects file coding
the way Emacs does.

- I would expect Emacs users to believe thata search from within Emacs
would autodetect coding system since Emacs does it. (Eli disagrees on

What can we do? The options I can see are:

- Use powershell + select-string (+ another cmdlet for dir tree
searching) on w32 by default. That has two benefits:

  1. Users on w32 does not have to install grep+find. But on older
systems they have to install powershell. Anyway it is easy to test for
powershell and use it if it is installed. (A problem is the hardcoding
of parameters to grep, like -i, but that can be resolved).

  2. Make an internal grep command in Emacs. A naive version in elisp
is quick to write but will be inefficient especially for large files.
A C version will require some restructuring of insert_file_contents,
but seems otherwise not hard to code. (Except perhaps for buffering
for effiency, but I have no idea if that is needed.)

I think 2 is the best choice, but I do not expect anyone to write it
now. Maybe add it to our to-do list?

For the moment I suggest that we implement 1.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]