no-word.el fails on Windows NT

no-word.el fails on Windows NT

[poti]

I am looking for an emacs interface for reading Microsoft Word
documents. I have been using antiword, which is fine and has 
an emacs mode provided by no-word.el. This works fine on OSX and 
Linux. However, when I visit a doc file on Windows NT, I get the
following error:

- is not a Word Document.


This appears to be related to the following elisp code:
	  (if file (replace-regexp-in-string " " "\\ " file t t) "-")
which is concatenated to the command "antiword" and options.
This is in the no-word function, where file is optional. 
Apparently, visiting the file does not pass a file to this function. 
This is as much as I can figure out. Why is the behavior different on 
Windows, is there a fix that will work as expected across platforms?

Also, is there a mode for Wv? If not, I thought if I could understand 
how no-word.el works, I would try modifying it to work for Wv.

The problem persists as of the following Emacs:
GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
 of 2007-05-20 on NEUTRINO

Re: no-word.el fails on Windows NT

[Eli Zaretskii]

> Date: Wed, 23 May 2007 18:17:03 -0400
> From: poti@potis.org
> 
> I am looking for an emacs interface for reading Microsoft Word
> documents. I have been using antiword, which is fine and has 
> an emacs mode provided by no-word.el. This works fine on OSX and 
> Linux. However, when I visit a doc file on Windows NT, I get the
> following error:
> 
> - is not a Word Document.
> 
> 
> This appears to be related to the following elisp code:
> 	  (if file (replace-regexp-in-string " " "\\ " file t t) "-")
> which is concatenated to the command "antiword" and options.
> This is in the no-word function, where file is optional. 
> Apparently, visiting the file does not pass a file to this function. 
> This is as much as I can figure out. Why is the behavior different on 
> Windows, is there a fix that will work as expected across platforms?

I think this is a bug in no-word.el: it assumes that the shell invoked
by shell-command-on-region is a Unixy shell, and so uses that shell's
quoting rules to escape-protect spaces in file names.  But on Windows,
the standard shell is cmd.exe, which doesn't understand those quoting
rules.

Try to change the above line to this (untested):

	(if file (setq file (shell-quote-argument file)))

(this uses the quoting rules suitable for the underlying platform's
shell).

Note that there are 2 more instances of such quoting in no-word.el;
you may wish to modify them as well.

Also, you should probably report the problem to the author.

Re: no-word.el fails on Windows NT

[poti]

On 10:21 Thu 24 May     , Eli Zaretskii wrote:
> > Date: Wed, 23 May 2007 18:17:03 -0400
> > From: poti@potis.org
> > 
> > I am looking for an emacs interface for reading Microsoft Word
> > documents. I have been using antiword, which is fine and has 
> > an emacs mode provided by no-word.el. This works fine on OSX and 
> > Linux. However, when I visit a doc file on Windows NT, I get the
> > following error:
> > 
> > - is not a Word Document.
> > 
> > 
> > This appears to be related to the following elisp code:
> > 	  (if file (replace-regexp-in-string " " "\\ " file t t) "-")
> > which is concatenated to the command "antiword" and options.
> > This is in the no-word function, where file is optional. 
> > Apparently, visiting the file does not pass a file to this function. 
> > This is as much as I can figure out. Why is the behavior different on 
> > Windows, is there a fix that will work as expected across platforms?
> 
> I think this is a bug in no-word.el: it assumes that the shell invoked
> by shell-command-on-region is a Unixy shell, and so uses that shell's
> quoting rules to escape-protect spaces in file names.  But on Windows,
> the standard shell is cmd.exe, which doesn't understand those quoting
> rules.
> 
> Try to change the above line to this (untested):
> 
> 	(if file (setq file (shell-quote-argument file)))
> 
> (this uses the quoting rules suitable for the underlying platform's
> shell).
> 
> Note that there are 2 more instances of such quoting in no-word.el;
> you may wish to modify them as well.
>

I tried your suggestion. It failed in the same way. When the 
no-word command is called by the interactive function through 
M-x no-word-find-file everything works. The problem appears 
to be in what happens when a file is visited with C-x C-f, in
particular, with how "-" is understood in Windows.

> Also, you should probably report the problem to the author.

I will forward a copy of this to him.

Re: no-word.el fails on Windows NT

[Eli Zaretskii]

> Date: Thu, 24 May 2007 16:07:12 -0400
> From: poti@potis.org
> 
> > 	(if file (setq file (shell-quote-argument file)))
> > 
> > (this uses the quoting rules suitable for the underlying platform's
> > shell).
> > 
> > Note that there are 2 more instances of such quoting in no-word.el;
> > you may wish to modify them as well.
> >
> 
> I tried your suggestion. It failed in the same way.

I assume you remembered to byte-compile the modified version and
reload it (or restart Emacs).  If you did, then my analysis seems to
be incorrect.  But I think the change I suggested is correct anyway.

Re: no-word.el fails on Windows NT

[poti]

On 08:31 Fri 25 May     , Eli Zaretskii wrote:
> > Date: Thu, 24 May 2007 16:07:12 -0400
> > From: poti@potis.org
> > 
> > > 	(if file (setq file (shell-quote-argument file)))
> > > 
> > > (this uses the quoting rules suitable for the underlying platform's
> > > shell).
> > > 
> > > Note that there are 2 more instances of such quoting in no-word.el;
> > > you may wish to modify them as well.
> > >
> > 
> > I tried your suggestion. It failed in the same way.
> 
> I assume you remembered to byte-compile the modified version and
> reload it (or restart Emacs).  If you did, then my analysis seems to
> be incorrect.  But I think the change I suggested is correct anyway.
>
I am burning Emacs to a DVD. I have placed no-word.el in site-lisp/
where it is loaded by site-start.el. It is possible that I got my
DVDs mixed up. I will check tomorrow. However, I did not byte-compile
this file. Is this necessary? I greatly appreciate your guidance on
this. 

Though I have used Emacs for some time, I only started learning
about the inner workings this semester. It seemed to me that things
worked without byte-compiling. In fact, transplanting Emacs binaries from
foreign platforms seemed to work leading me to hope I might be able to
pay a speed penalty to save space on a cross-platform DVD. 
If my assumptions are wrong, I would be grateful for advice on where 
I should look to learn more. So far my main reading has been the
Emacs Lisp Reference Manual, mostly as needed to learn basic operations.

-Poti

Re: no-word.el fails on Windows NT

[Eli Zaretskii]

> Date: Fri, 25 May 2007 02:22:34 -0400
> From: poti@potis.org
> 
> I did not byte-compile this file. Is this necessary?

It's not necessary (although byte-compiled files will run faster).  I
assumed (incorrectly, it seems) that the previous version was
byte-compiled; if it was, and the modified version wasn't, then Emacs
will load the old byte-compiled version in preference to the new one.

> It seemed to me that things worked without byte-compiling.

They should work, albeit slower.

Re: no-word.el fails on Windows NT

[poti]

On 10:21 Thu 24 May     , Eli Zaretskii wrote:
> > ..., when I visit a doc file on Windows NT, I get the
> > following error:
> > 
> > - is not a Word Document.
> > 
> > 
> > This appears to be related to the following elisp code:
> > 	  (if file (replace-regexp-in-string " " "\\ " file t t) "-")
> > which is concatenated to the command "antiword" and options.
> > This is in the no-word function, where file is optional. 
> > Apparently, visiting the file does not pass a file to this function. 
> 
...
> I think this is a bug in no-word.el: it assumes that the shell invoked
> by shell-command-on-region is a Unixy shell, and so uses that shell's
> quoting rules to escape-protect spaces in file names.  But on Windows,
> the standard shell is cmd.exe, which doesn't understand those quoting
> rules.
> 
> Try to change the above line to this (untested):
> 
> 	(if file (setq file (shell-quote-argument file)))
> 
> (this uses the quoting rules suitable for the underlying platform's
> shell).
> 
...
> 
> Also, you should probably report the problem to the author.
> 
With the help of the author, I was able to come up with a solution. 
Rather than treating "-" as input from stdin, Windows treated "-" as 
a filename. Changing this to (buffer-name) worked across platforms. I 
added shell quoting, for good measure. Unless I hear of a more elegant 
solution, I will update  no-word.el on the Emacs wiki. 
Thank you for the help.
-Poti
> 
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: no-word.el fails on Windows NT

[Kevin Rodgers]

poti@potis.org wrote:
> On 10:21 Thu 24 May     , Eli Zaretskii wrote:
>> Try to change the above line to this (untested):
>>
>> 	(if file (setq file (shell-quote-argument file)))
>>
>> (this uses the quoting rules suitable for the underlying platform's
>> shell).
>>
> ...
>> Also, you should probably report the problem to the author.
>>
> With the help of the author, I was able to come up with a solution. 
> Rather than treating "-" as input from stdin, Windows treated "-" as 
> a filename. Changing this to (buffer-name) worked across platforms. I 
> added shell quoting, for good measure. Unless I hear of a more elegant 
> solution, I will update  no-word.el on the Emacs wiki. 

(buffer-name) does not return a file name that corresponds to stdin on
any platform, so why does that work?

If you want the name of the file that the buffer is visiting, use
(buffer-file-name) or (file-name-nondirectory (buffer-file-name)),
shell-quoted of course.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: no-word.el fails on Windows NT

[poti]

On 08:05 Fri 01 Jun     , Kevin Rodgers wrote:
> poti@potis.org wrote:
> >With the help of the author, I was able to come up with a solution. 
> >Rather than treating "-" as input from stdin, Windows treated "-" as 
> >a filename. Changing this to (buffer-name) worked across platforms. I 
> >added shell quoting, for good measure. Unless I hear of a more elegant 
> >solution, I will update  no-word.el on the Emacs wiki. 
> 
> (buffer-name) does not return a file name that corresponds to stdin on
> any platform, so why does that work?
I did in fact want the file name. It seemed to me (buffer-name) would
work out to shell-command-on-region issuing a shell command roughly
amounting to "antiword myfile.doc"

The author was using (doc-name (buffer-name)) to name the temp buffer
into which the output of antiword was placed. That is where I got
the idea to use (buffer-name).

The reason it was working is because in the cases I tried, it did in
fact work out to this. However I see from your correction how this
could fail.

Reading how find-file-noselect works, I see the buffer
name was coming from create-file-buffer, which could have named the
buffer myfile.doc<2>, which would not work.

> 
> If you want the name of the file that the buffer is visiting, use
> (buffer-file-name) or (file-name-nondirectory (buffer-file-name)),
> shell-quoted of course.

Thank you for showing the right way to do this.
-Poti