On Wed, Jun 30, 2021 at 12:24 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > I noticed an issue when trying to use flyspell (or ispell) using
> > hunspell from a local MS Windows system on a TRAMP file. It results in
> > an error that it can't find the file "/sshx:server:/path/to/NUL". I
> > narrowed this down to the fact that
> > `ispell-find-hunspell-dictionaries' calls `call-process' with `infile'
> > set to `null-device'.
>
> `call-process' doesn't know of remote files. You must use `process-file' instead.

That's not a problem; it's actually the right thing to do in this
case, I think. flyspell/ispell is trying to use my local version of
hunspell on the contents of a remote buffer. Since flyspell/ispell
just look at the buffer contents and not the actual file, it can use
`call-process'.

> It is not a good idea to use `null-device' as INFILE, just use nil. At
> least in the `process-file' case, Tramp shall know which value to take
> for `null-device'.

That fix would also work (see the attached patch).

However, when I read the `call-process' documentation, it says that
when `default-directory' is remote, it runs the program from "~".
That's fine overall, and means it's a good way to be sure you're
always running a process locally. It's just that when you do this,
INFILE's path is expanded relative to the remote directory. I don't
think that can ever work, since `call-process' doesn't know how to
open a TRAMP file. Because of that, it makes more sense to me that
you'd expand INFILE's path relative to wherever PROGRAM will be run
from. That means that when `default-directory' is remote, both PROGRAM
and INFILE are expanded relative to "~". That's more consistent, and
my first patch would hopefully prevent similar errors anytime
`call-process' is used from a remote buffer.