Re: 23.0.50; ps-print-buffer-with-faces hangs on w32

["Lennart Borgman (gmail)" <lennart.borgman@gmail.com>]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>>>
>>> What exactly does this mean?
>>>
>>> Does any Emacs variable have the value "C:\\PRN"?
>>
>> The variable `printer' above.
> I don't have a variable `printer', is this from an external package you 
> have installed?

Hi Jason,

No, it is a variable in the function I mentioned in the bug report:

   Emacs hangs in direct-print-region-helper in the call to

     (write-region start end printer t 0)

   at the end of the function. Emacs is completely hanged. I have to
   kill Emacs from Windows Task Manager.

This function is in dos-w32.el.

> I do have a variable `printer-name', but it's default value on Windows 
> is the device name "PRN",

I have the same.

> not "C:\\PRN"

This is what Emacs has translated "PRN" to at the end of the function above.

>>> What is a "Windows printer"?
>>
>> I forgot what these printers are called. It seems like they are called 
>> "GDI printers" or "winprinters".
> Calling them winprinters suggests that there is something that makes 
> them a win over other more functional printers.

Maybe.

> Really the printer 
> hardware is not the issue, often the printer will be better supported by 
> Free Software like CUPS than by the manufacturers own Windows drivers, 
> so calling them Windows printers is also misleading. What you really 
> mean is that the Windows printer drivers that the manufacturer has 
> supplied are limited to supporting only GDI based printing, as they do 
> not expose a character device (and are connected via USB, so the COM or 
> PAR character devices are not automatically available)

Correct.

> that could be 
> used to print directly to the printer in text mode or whatever command 
> language(s) that the printer supports natively (eg Postscript, PCL or 
> ESC/P). This problem can often be worked around by sharing the printer 
> from Windows, and setting the printer-name within Emacs to the network 
> share path of the printer (eg "//localhost/printer").

Yes, that is perhaps a nice little trick. Though I had never had any 
reason to test it, but if you think it works then maybe this is 
something worth mentioning on (info "(emacs) Windows Printing")?

> But it is unlikely that a printer with such limited drivers supports 
> Postscript natively, so to use the ps-print commands, you'll need to set 
> up a software postscript interpreter such as Ghostscript anyway.

That is correct, but it is not the problem I am reporting. I must have 
made some bad mistake in my initial bug report since both you and Eli 
misunderstood me this way.

What I was reporting was that under certain (rather common conditions) 
Emacs can hang if a user tries to print a file. Emacs hangs very badly 
and can not be interrupted. You have to kill Emacs from outside - and 
that of course means that the user can loose data.

(It has nothing per se with ps-print-* to do, it hangs in the same way 
if one uses print-buffer. I actually did M-x ps-print-buffer just to see 
how Emacs failed.)

So my question is what we can do about this?

I doubt that there is anything we easily can do technically about it 
since I notice that in a cmd.exe console

    copy /b some-non-emtpy-file.txt PRN:

hangs the console window rather badly.

I think however that we should do something since GDI printers are 
common on w32. What we can do is to warn the user. The best way IMO 
would be to add a y/n question in the function 
direct-print-region-helper in dos-w32.el that warns the user that Emacs 
might hang. (And of course an option to bypass the question.)