bug#2058: 23.0.60; bewildering behavior when visit new file throw.pdf

[Drew Adams]

Hi Tassilo and Alan, 

The discussion so far has already covered pretty much everything: 

- it's typically a user-error case, not a use case
- the message is too long (probably for all cases - my guess)
- the message is too complex and inappropriate for this error case

> Sure.  So what's your advice how to handle this situation?  
> Check if the file is existent (and non-empty) and if not, print a message and
> fallback to fundamental mode?

Yes, I think so.

Dunno if doc-view handles an existing empty file - I'd guess not. If it does not
then there are two error cases here: (1) a new, empty buffer and (2) an existing
empty file.

It would be good to treat each of these error cases specially: differently from
the normal doc-view bad-PDF error intended by the current message. In both of
these cases, the buffer should not be put in doc-view mode, but just kicked into
fundamental mode with an error message. 

The message should not assume the user knows anything about doc view or PDF
files. It should just point out that the file (a) doesn't exist or (b) is empty.

An alternative would be not to visit the empty file at all - just display an
error. But there might be a (marginal) use case for letting the user edit the
file in some non-doc-view mode (e.g. fundamental) and even save it.

FWIW, I came upon this by trying to create a few phony files to do some Dired,
shell etc. testing with. I wanted files (not just buffers) with different,
recognized extensions, and I didn't want to take the time to find real PDF files
etc. and copy them. Yes, I could have created files with a different extension
(*.el, *.txt) and then renamed them, but I didn't. ;-)

Another case is what happens if a user visits a non-empty text file named
foo.pdf? Again, the buffer should be put in fundamental mode and an error
message raised. The message should say that *.pdf is associated with doc-view
mode, but this is not a well-formed PDF file. IOW, the not-valid-PDF message
must make sense also to a user unfamiliar with images.

If you want to give additional info about the invalid PDF in the case of a
normal bad-PDF file, then consider giving first such a short message, but
mention that the user can hit some key for more information. When s?he hits that
key, pop up a buffer with the detailed diagnosis for the bad PDF.

FYI - I filed a similar bug for image file: #2077.