From: "Drew Adams" <drew.adams@oracle.com>
To: "'Tassilo Horn'" <tassilo@member.fsf.org>
Cc: emacs-pretest-bug@gnu.org, 2058@emacsbugs.donarmstrong.com
Subject: bug#2058: 23.0.60; bewildering behavior when visit new file throw.pdf
Date: Tue, 27 Jan 2009 07:44:14 -0800 [thread overview]
Message-ID: <001d01c98096$1bb8b7b0$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <87tz7lt6n7.fsf@thinkpad.tsdh.de>
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.
next prev parent reply other threads:[~2009-01-27 15:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.5816.1232925816.26697.bug-gnu-emacs@gnu.org>
2009-01-27 9:55 ` bug#2058: 23.0.60; bewildering behavior when visit new file throw.pdf Tassilo Horn
2009-01-27 12:02 ` Alan Mackenzie
2009-01-27 12:43 ` Tassilo Horn
2009-01-27 14:42 ` Alan Mackenzie
2009-01-27 14:46 ` Tassilo Horn
2009-01-27 16:03 ` Tassilo Horn
2009-01-27 16:20 ` Drew Adams
2009-01-28 8:48 ` Kevin Rodgers
[not found] ` <mailman.6064.1233133417.26697.bug-gnu-emacs@gnu.org>
2009-01-28 20:28 ` Tassilo Horn
2009-01-27 15:44 ` Drew Adams [this message]
2009-01-27 22:58 ` Richard M Stallman
2009-01-28 7:45 ` Tassilo Horn
2009-01-25 23:09 Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001d01c98096$1bb8b7b0$0200a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=2058@emacsbugs.donarmstrong.com \
--cc=emacs-pretest-bug@gnu.org \
--cc=tassilo@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.