Re: Debugging aspell problems

[Eli Zaretskii]

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Wed, 05 Aug 2020 21:32:48 +0200
> 
> I have created two Windows scripts to make it more reproducible. One is
> called chain.cmd and the other one is myaspell.cmd. The first one simply
> pulls lines of text and copies them to a file
> [...]
> c:\msys64\mingw64\bin\aspell.exe  -a -m -B --encoding utf-8
> Emacs input
> !
> +
> 
> The Emacs copy is wating for output but has not flushed out the line
> buffer that contains the word. Note that here the script that is waiting
> for input is chain.cmd, not aspell. Hence, one cannot really claim that
> the problem is msys.

Thanks for the data points, but I'm afraid I'm not convinced.  You've
used a very complicated setup, introducing many additional unknowns
into the equation: cmd.exe, batch files, redirection, more pipes, etc.
This could completely hide the real issues, and at best complicate the
investigation to a great extent.

Let's use much more direct method: Process Explorer from Sysinternals.
Please configure the Process Explorer (via View->Select Columns) so
that it shows the following attributes for each process:

 . I/O Writes
 . I/O Write Bytes

Then start "emacs -Q", configure it to use Aspell, create the
LaTeX-mode buffer with the word "buffer", type "M-$" several times,
and watch the above 2 counters.

What I see on my system (with Hunspell) is that each time I type M-$,
the Emacs process's I/O Writes counter increases by 4, and the I/O
Write Bytes increases by 18.  Which is exactly what I would expect,
since ispell.el sends these 4 strings to the speller:

   !\n
   +\n
   %\n
   ^buffer\n

and each \n character gets converted into a \r\n pair by low-level
I/O code in w32.c.

These results tell me that all the stuff that needs to be written to
the pipe does indeed get written, and no buffering issue is involved.
Which makes sense, since the Emacs implementation of subprocess I/O on
MS-Windows uses unbuffered writes, and on top of that each command we
send to the speller is terminated by a newline, so flushing buffers
should not be relevant to this scenario.

Do you see the same results, or do you see something different?

Stepping back a notch, I don't really see how buffering could be the
first suspect, given your description.  You are saying that the same
procedure works with foo.txt buffer in Text mode, and fails in LaTeX
mode, but the low-level I/O code which could be responsible for some
kind of buffering has no idea about the major mode of the buffer which
is being spell-checked.  Only ispell.el, on the one side, and the
speller itself on the other side, are aware of the differences between
Text mode and LaTeX mode.  So the explanation is likely to be found in
one of these two places, not in the low-level buffering machinery.
Since your tracing shows that process-send-string did get called with
"^buffer" in the LaTeX case, IMO the first possible reasons to explore
are:

  . does Aspell respond to the ^buffer request, when in "tex" mode?
  . do you perhaps have some local/private dictionary that affects the
    issue?